How to Format JSON and Fix the Errors That Break It
JSON is simple until it is not. One stray comma or a single quote in the wrong place, and the whole document refuses to parse. Here is how to format JSON properly — and how to find the five errors that cause most failures.
Start by formatting what you have
The first step with any JSON you did not write yourself is to format it. An API response usually arrives as a single line, and a single line hides the structure: you cannot see where one object ends and the next begins, and you cannot spot a missing brace. Paste the text into a formatter — the DevKit JSON Formatter runs entirely in your browser — and expand it with two-space indentation. If the document is valid, you now have a readable version you can scan. If it is not valid, the formatter will fail, and that failure is itself useful information: the error message tells you where the parser stopped, and that is where the problem is.
Formatting is not just cosmetic. A well-formatted document makes every other debugging step easier, because the line numbers in the error message now point at lines you can actually read. Make formatting the first move, every time, before you start editing by hand.
The five errors that break JSON most often
1. The trailing comma. This is the most common JSON error, and it happens when a line is deleted from a hand-edited file. In {"a": 1, "b": 2,} the comma after 2 promises another key, and the parser finds the closing brace instead. The error is reported at the brace. The fix is to delete the comma. JavaScript object literals allow trailing commas; JSON does not, and that difference catches people who copy code from a JavaScript file into a JSON file.
2. Single quotes instead of double quotes. JSON strings and keys must use double quotes. {'name': 'Ada'} is valid JavaScript and invalid JSON. The fix is to replace the single quotes with double quotes — but be careful with apostrophes inside string values, like "O'Brien", which are fine in double quotes and would break a single-quoted string. If you are converting a JavaScript object to JSON, a formatter that accepts the JavaScript form can do the conversion, but the safest route is to write double quotes from the start.
3. Unquoted or missing keys. Every key in a JSON object must be a quoted string. {name: "Ada"} fails for the same reason single quotes fail: it is JavaScript, not JSON. The same error appears when a quote is missing entirely, as in {"name: "Ada"}, where the parser reads name: as part of the string and then chokes. When the error message says it expected a double-quoted property name, look at the key just before the reported position — the problem is almost always there.
4. Comments. JSON has no comments. A line starting with // or a block wrapped in /* */ is rejected, even though many config formats that look like JSON allow them. If your file needs notes for humans, keep them outside the JSON — in a separate readme, or in a format like JSONC that explicitly supports comments. Before pasting a config file into a strict JSON parser, strip the comments out.
5. Values that are not JSON values. A JSON value must be a string, a number, true, false, null, an object, or an array. JavaScript values like undefined, NaN, and Infinity are not allowed, and neither are dates written bare, like 2026-11-07 — that must be a quoted string, "2026-11-07". A function, a regular expression, or a variable reference is also invalid. If you are generating JSON from code, use your language’s JSON encoder rather than building the string by hand; the encoder handles quoting, escaping, and special values correctly.
How to read an error message
A JSON parser reports the first error it finds, and only the first. That means a document with three errors will fail three times, once per fix, and that is normal — fix one, validate again, and repeat. The position in the message is a character offset from the start of the document, and most tools convert it to a line and column. The reported position is where the parser gave up, which is usually at or just after the actual mistake. A missing closing quote, for example, is often reported several lines later, because the parser keeps reading the following lines as part of the string until it finds the next quote. When the reported position looks wrong, look backward: the real error is often the last quote, comma, or brace before it.
Another useful habit is to bisect a large document. If a thousand-line response fails and the error position is unhelpful, split the document in half and validate each half — wrapping each in braces or brackets as needed — and keep splitting the failing half until the error is in a few lines you can read. It is slower than reading the error message, but it works when the message does not. Most editors with JSON support also help: they underline the error, show matching braces, and flag duplicate keys, which a plain parser does not always do.
Formatting choices that prevent errors
A few habits make JSON errors rare. Use two-space indentation — it is the most common convention, it keeps lines short, and it matches what most APIs and formatters produce. Keep one key per line in objects, and put each array item on its own line when the array is long. Avoid editing JSON by hand in a plain text editor when you can edit it in an editor with JSON validation, which catches a trailing comma the moment you type it. And when you generate JSON in code, never build it with string concatenation: use JSON.stringify in JavaScript, json.dumps in Python, or the equivalent in your language. Hand-built JSON is where the escaping errors live — an unescaped quote inside a string value, a backslash that was not doubled, or a newline inside a string, which JSON forbids (use \n instead).
Finally, remember that formatting and minifying never change the data. You can format a document to read it, fix the errors, and minify it again for storage or transmission, and the values will be identical — with one exception worth knowing. Numbers are parsed as double-precision floating point, so integers longer than about 15 or 16 digits can lose precision when a document is parsed and re-serialized. If your data includes very large IDs, store them as strings. That one rule, plus the five errors above, covers nearly every JSON failure you will meet in practice.
Try it now: paste a messy API response into the JSON Formatter & Validator and see whether it parses — and if it does not, let the line and column in the error message point you to the fix.