Checkpoint: Confirm which format your error is in — a raw position number or an explicit line/column pair — before moving to the next step, since they require different conversion approaches.

Step 2: Convert a Character Position to a Line Number

If your error only gives a position (like position 87), you need to map that offset back to a line. This one-liner does it in Node:

const raw = require('fs').readFileSync('data.json', 'utf8');
const position = 87;
const lines = raw.slice(0, position).split('\n');
console.log(`Line ${lines.length}, Column ${lines[lines.length - 1].length + 1}`);

This works by slicing the string up to the failing position, then counting how many newlines occurred before it — the length of that array is the line number, and the length of the last fragment is the column.

Expected output:

Line 4, Column 3

Now you have an exact coordinate instead of a guess.

Step 3: Isolate Just the Offending Line

Don't scroll through the whole file. Extract only the failing line and the two around it for context:

const target = lines.length; // from Step 2
const context = raw.split('\n').slice(target - 2, target + 1);
console.log(context.join('\n'));

Expected output (example):

  "user": {
    "name": "Ada",
    "roles": ["admin", "editor",]
  }

That trailing comma after "editor" is the actual bug — a pattern that's invisible when you're staring at 200 lines but obvious in a 3-line window.

Step 4: Check Against the Six Most Common JSON Syntax Failures

JSON's grammar is deliberately stricter than JavaScript object literals, and that gap is where most parse errors come from.

If your snippet from Step 3 matches one of these, you likely have your answer already. If it doesn't cleanly match, the next step gives you a second, visual pass.

Step 5: Cross-Check with a Line-Level Validator

Manual position math is reliable but slow when you're debugging repeatedly during development. A JSON Formatter & Validator does the same slicing logic from Steps 2–3 automatically and highlights the exact character inline, which is faster once you already understand what's happening under the hood.

Paste the same snippet in, and the tool should flag the identical position you calculated manually — that agreement is itself a useful check that you diagnosed the failure correctly.

Checkpoint: The validator's reported line and your Step 2 calculation should match. If they don't, you're likely looking at a different error than the one your original stack trace reported — re-run the parse and get a fresh message before continuing.

Step 6: Fix, Then Guard Against Regressions

Once the syntax is corrected, don't just re-run JSON.parse() once and move on. If this JSON is generated programmatically (from a template string, string concatenation, or manual API response construction), the same bug will recur. Two guards are worth adding:

Comparison — manual template strings vs. JSON.stringify(): hand-built JSON strings are where trailing commas and unescaped characters creep in; JSON.stringify(obj) cannot produce invalid JSON, because it serializes from an actual object rather than concatenated text.

If the malformed JSON is coming from a regex-based string transformation (a common source when someone is stripping fields with pattern matching before parsing), a Regex Explainer can show you exactly which characters your pattern is consuming or leaving behind — a frequent hidden cause of "line 4" errors that only show up on certain inputs.

Common Errors

• Unexpected end of JSON input on a fetch response — Cause: the response body was consumed twice (once by .text() and again by .json()), or the request was aborted mid-stream. Fix: log response.status and the raw text length before calling .json().
• Error position looks wrong after minifying — Cause: minified JSON has no newlines, so "line 1" is the entire file. Fix: run the formatter step first to reintroduce line breaks, then re-parse to get a meaningful position.
• Works in a validator but fails in code — Cause: the string in code has a Byte Order Mark (BOM) or invisible Unicode character at the start. Fix: strip it with raw.replace(/^\uFEFF/, '') before parsing.

Once your JSON is valid and you're consuming it in a typed codebase, a natural next step is generating interfaces directly from the corrected payload with a JSON to TypeScript Converter, so the same structural mistakes get caught by the compiler next time, not by a runtime crash.