The Many Ways 'Almost-JSON' Breaks (and How Auto-Repair Tools Fix It)

"Invalid JSON" almost never means someone sat down and typed nonsense. It usually means perfectly reasonable data got passed through the wrong assumption somewhere along the way — written by a human who was thinking in JavaScript, copied from a tool that never promised strict JSON in the first place, or pulled out of a log line that wraps it in other text. The JSON specification itself is short and strict on purpose: double-quoted keys, double-quoted strings, no trailing commas, no comments. Almost none of the JSON-shaped text people actually encounter in the wild fully honors that. It's worth walking through where the mismatches actually come from, because the pattern in each case is different, and recognizing which one you're looking at is often faster than reading the parser's error message.

JavaScript objects that look like JSON but aren't

JSON's syntax was deliberately modeled on JavaScript object literals, which is exactly why it's so easy to confuse the two — and why so much "JSON" in the wild is actually just a JavaScript object that happens to overlap with JSON syntax most of the time. Someone copies a config object straight out of a .js file:{ name: 'widget', count: 3, tags: ['a', 'b',] }. Every one of those choices is completely legal JavaScript — unquoted keys, single-quoted strings, a trailing comma after the last array element — and every one of them is a hard syntax error in strict JSON. The same thing happens with values: JavaScript allows undefined, NaN, and Infinity as literal values, and none of them exist in the JSON spec, which only recognizes numbers, strings, booleans, null, objects, and arrays. Anyone who's grabbed a state object out of browser devtools, or copied a route config from a Node.js file, has run into this exact wall.

Hand-edited config and API testing tools

A second, very different source is simple manual editing. Someone opens a.json config file, adds a fourth field to an object that used to have three, and forgets that the third line — which used to be the last property — still needs its trailing comma removed, or conversely forgets to add one when inserting a line in the middle. Comments are the other frequent casualty: developers instinctively want to leave a// TODO: rotate this key note next to a config value, but JSON has no comment syntax at all, so tools that accept "JSON with comments" (like VS Code's own settings files, which technically use JSONC) produce files that fail the moment they're run through a strict parser elsewhere. API-testing tools compound this: Postman, Insomnia, and browser devtools all let you paste a request body loosely, and it's common to build that body by trial and error directly in the tool, only formalizing it into real JSON once it's copied somewhere that enforces the spec.

Log output and embedded JSON

A third common pattern isn't malformed JSON at all — it's valid JSON sitting inside something that isn't. Application logs frequently interleave a JSON payload with a timestamp and log level prefix: 2026-07-19T10:02:11Z INFO {"userId": 4821, "action": "login"}. Copy that whole line into a JSON parser and it fails immediately, not because the JSON part is wrong, but because there's text around it that was never supposed to be parsed as JSON in the first place. The same thing happens with JSON returned inside error messages, wrapped in a Python repr() string with escaped quotes, or embedded inside an XML or HTML response as a serialized blob. Each case needs the surrounding wrapper stripped or unescaped before the JSON underneath is even reachable, which is a subtly different problem from a genuine syntax error inside the JSON itself.

Encoding and copy-paste damage

A more mechanical source of breakage comes from the act of moving text between applications. "Smart quotes" are the classic offender: pasting JSON out of a word processor, a Slack message, or certain note-taking apps silently swaps straight double quotes (") for curly typographic ones (" and "), and a strict JSON parser treats those as ordinary characters rather than string delimiters, producing a confusing error far from where the actual problem is. Copying from a PDF or a terminal with line-wrapping enabled can also silently insert stray line breaks in the middle of a long string value. None of these are conceptual misunderstandings of JSON's rules — they're artifacts of the pipeline the text traveled through before it landed in a parser, and they're often the hardest category to spot by eye, since the character that broke everything looks almost identical to the one that should be there.

Truncated and concatenated payloads

Finally, there's a category of breakage that has nothing to do with syntax choices and everything to do with incomplete data: a response cut off mid-stream because a request timed out or a buffer size limit was hit, leaving a document that just stops partway through an array; or the opposite problem, two separate JSON documents concatenated back to back with no separator because something logged two objects in a row without a delimiting comma or newline. A parser encountering either of these reports a generic "unexpected end of input" or "unexpected token" error that doesn't distinguish "this was cut off" from "this has a typo," even though the fix is completely different in each case — one needs the missing tail re-fetched, the other needs to be split apart.

Recognizing which of these categories a given error falls into is often more useful than memorizing JSON's grammar rules, because it tells you where to actually look — at the source system, the copy-paste path, or the file's structure — rather than staring at a character position. That's the gap a tool like theJSON Formatter / Corrector is built to close for the syntax-level cases: it recognizes the common non-standard patterns described above and fixes what it safely can, so the underlying data becomes usable without needing a full manual rewrite for every stray comma or curly quote.