Why You Can't Just Eyeball a Broken JSON File

A missing comma between two properties, an extra closing brace, a trailing comma before a bracket - any one of these breaks a JSON file completely, and none of them look wrong to a person scanning the text. JSON's syntax is simple enough that people assume they can read it the way they read code and catch a typo by eye, the way you'd notice a missing semicolon. On a ten-line config file, maybe. On a 400-line API response pasted into a text editor, the odds drop fast, and the file still looks perfectly fine right up until something tries to parse it and fails.

Where a broken JSON blob actually comes from

It's rarely a file someone sat down to write by hand. It's an API response copied out of a browser's network tab or Postman to check why a request failed. It's a config file - an appsettings.json, a bundler config, a hand-maintained list of feature flags - edited by someone in a hurry who added one entry and forgot the comma before it. It's a value pasted out of a Slack message or a bug report, where the original formatting is already gone and everything reads as one dense paragraph of punctuation.

In all three cases the person looking at it isn't trying to read JSON for its own sake. They're trying to answer one question - is this valid, and if not, where's the problem - as fast as possible, on their way to fixing something else.

Why scanning by eye specifically fails here

JSON's punctuation carries almost no visual weight. A comma and a period differ by a few pixels. A curly brace and a square bracket are easy to swap without noticing, especially at the end of a long line. Indentation only helps if it's consistent, and copy-pasted or minified JSON usually isn't indented at all - it's one continuous line, sometimes tens of thousands of characters long, with no visual landmark to anchor your eyes on.

Nesting makes it worse. The bracket that doesn't match its opening brace might be forty lines away from the line that actually looks wrong to you, because the error a parser reports is where it noticed the problem, not necessarily where the typo physically sits. A person scanning top to bottom has no reliable way to hold that structure in their head past a few levels deep.

There's also a case that looks like it should be an error and isn't: a duplicate key. {"id": 1, "id": 2} is syntactically valid JSON - a parser such as the browser's JSON.parse silently keeps the last value and drops the first, with no warning at all. Someone eyeballing that file wouldn't flag it as a problem, because there isn't one from the parser's point of view, even though it's almost certainly not what the person who wrote the file intended. The formatter keeps both lines exactly as written, so once the file is laid out the repeat is easy to spot.

What a validator actually does that your eyes can't

A parser doesn't look for things that seem wrong. It applies the JSON grammar one character at a time and stops the instant a rule is broken. The browser's own JSON.parse already does exactly this - it's the same function this site's formatter runs - but out of the box it reports the failure as a raw character offset ("Unexpected token } in JSON at position 4192"), which is exact but not something a person can use to find the line in an editor. Turning that offset into a line and column number just means walking the text and counting newline characters up to that position - simple, and the one piece of information that actually gets you to the fix.

The part that matters if the blob isn't a test fixture

Often what's broken isn't a throwaway example - it's a real API response carrying real data, or an internal config with values that shouldn't leave the machine they're on. Pasting that into the first online formatter that shows up in a search means trusting a server you know nothing about with whatever's inside it. That's a real cost most people don't think about until it's too late to undo.

This site's JSON formatter runs the whole check in your browser. The text is never sent anywhere, not even to confirm whether it's valid - the same JSON.parse call your browser already has runs locally, and the result stays on your screen. If you're also weighing whether to keep the result readable or ship it minified once it's valid, that's a separate decision, and a different one from finding the error in the first place.