JSON Formatter Explained: Common Errors and How to Fix Them

JSON (JavaScript Object Notation) is the default format for moving data between servers, APIs, and applications. It's built from just two structures — objects (key-value pairs) and arrays (ordered lists) — which is exactly why it's so widely supported and also why small syntax mistakes break it completely.

Why raw JSON is unreadable

Most JSON you'll actually encounter — an API response, a config file, a log entry — arrives as one unbroken line of text. Whitespace adds bytes without adding meaning for a machine, so it gets stripped before transmission. That's efficient to send and impossible to read, which is the entire reason a formatter exists: it reintroduces indentation and line breaks so a human can follow the structure, without touching the underlying data.

The errors that account for most "invalid JSON" messages

• Trailing commas — a comma left after the last item in an array or object, like [1, 2, 3,]. Valid in a JavaScript object literal, invalid in strict JSON.
• Single quotes — JSON requires double quotes for both keys and string values. {'key': 'value'} fails; it must be {"key": "value"}.
• Unquoted keys — JavaScript allows {key: "value"}, but JSON requires every key to be a quoted string.
• Missing or extra commas — a comma missing between two properties, or an extra one before a closing brace, is the single most common copy-paste error.
• Unescaped characters — a raw newline, tab, or backslash inside a string value breaks parsing; these need to be escaped as \n, \t, \\.
• JavaScript-only values — undefined, NaN, and functions are valid in JavaScript but have no JSON equivalent; they need to become null or a string.

Reading the error message

When a parser rejects JSON, the error usually says where it stopped. Older browsers reported only a character offset (for example "Unexpected token , in JSON at position 42"); current Chrome and Node.js also give a line and column. The offset counts characters from the start of the string, so it is easiest to use after you have formatted the surrounding structure.

Real error messages and what causes them

These are the exact messages Node.js 23 (the V8 engine used by Chrome) gives for the most common mistakes. Firefox and Safari word them differently, but the cause is the same.

• [1, 2, 3,] → Unexpected token ']' — a trailing comma in an array.
• {"a": 1, "b": 2,} → Expected double-quoted property name in JSON at position 16 (line 1 column 17) — a trailing comma in an object.
• {'name': 'Asha'} → Expected property name or '}' in JSON at position 1 — single quotes where double quotes are required. An unquoted key like {name: "Asha"} gives the same message.
• {"a": 1 "b": 2} → Expected ',' or '}' after property value in JSON at position 8 — a missing comma between two properties.
• A string containing a raw line break → Bad control character in string literal in JSON at position 15 — the newline must be written as \n.
• {"a": undefined} and {"a": NaN} → Unexpected token 'u' and Unexpected token 'N' — neither value exists in JSON.
• An empty string → Unexpected end of JSON input — nothing was received, which often means an empty API response.
• Unexpected token '<' — the "JSON" actually starts with <, so it is HTML. This is very common when a request returns an error page or a login redirect instead of data. Look at the raw response, not the parser.

Also note that JSON has no comments. A // comment inside a JSON file fails with the same "Expected ',' or '}'" style of message, even though the same text would be fine in a JavaScript file or a config format that allows comments.

Formatting vs. minifying

These are opposite operations on the same data. Formatting adds indentation so a human can read the structure. Minifying strips that whitespace back out to produce the smallest possible payload for a network request. Use formatted JSON while debugging or documenting an API, and minified JSON for the actual production payload.

The difference is real but modest. A list of 100 user records (id, name, email, active flag) measured 7,031 characters minified and 11,239 characters with 2-space indentation — about 60% larger. Web servers usually compress responses anyway, which shrinks that gap, so minifying matters most for very large payloads or data stored in size-limited places.

A quick debugging routine

1. Look at the raw text first. If it begins with < or contains words like "Error" or "Login", you received HTML, not JSON.
2. Paste it into the formatter. If it formats, the syntax is valid and the problem is in how your code uses the data.
3. If it fails, read the position and line/column in the error and check the characters just before that point — the real mistake is usually the character right before the one the parser complains about.
4. Fix one error at a time and re-run; a single missing quote can cause several confusing errors after it.
5. Once it parses, confirm the shape matches what your code expects: field names, nesting and types (a number sent as the string "42" is valid JSON but may break your logic).

Best practices

• Validate JSON before it ships to a production API — malformed payloads fail silently in a lot of client libraries.
• Keep nesting shallow where you can; JSON more than 4-5 levels deep is hard for the next person (including future you) to follow.
• Never paste real API keys or customer data into a third-party formatter, including this one — treat online tools as public by default.