JSON won the data format war by being simple, and then everyone discovered the simplicity has teeth: a single trailing comma kills the parse, single quotes are illegal, comments do not exist, and a sixteen-digit ID can silently change value in transit. This guide covers validating, formatting, and converting JSON with those teeth in mind, using our free JSON analyzer, which does all three in your browser.
In this guide
The four rules everyone breaks
JSON looks like JavaScript and is stricter than JavaScript, and the gap between the two is where almost every invalid document lives:
- Double quotes only.
{'name': 'Ana'}is valid JavaScript and invalid JSON; both keys and string values demand double quotes. - No trailing commas.
[1, 2, 3,]fails. The comma habit imported from code is the single most common JSON error in the wild. - No comments. The format has none, by deliberate design. Config dialects that allow them exist, but anything promising plain JSON will reject
//on sight. - No NaN, Infinity, or undefined. Numbers are finite decimals, missing values are
null, and that is the whole vocabulary.
All four are legal in the languages people write JSON inside, which is why hand-edited JSON breaks so reliably and why a validator earns its place in the workflow.
Validating: reading the error like a pro
A parser error names a position, not a cause: “unexpected token at line 14” routinely means the mistake is at line 13, a missing comma or unclosed bracket whose damage only becomes visible one token later. The efficient diagnosis order: look one line up from the reported position, check the four rules above, then check the brackets. The analyzer pairs the error with structure inspection, which catches the subtler second category, JSON that parses fine but has the wrong shape: a string where a number should be, an object where the code expects an array. Valid and correct are different bars, and APIs fail on both.
Formatting: minified vs readable
The same document has two legitimate costumes: minified, whitespace-free for transmission, and pretty-printed with indentation for humans. Conversion between them is lossless in both directions, the data never changes, only the whitespace, so format freely. Two working habits: pretty-print anything you are about to debug, because errors hide in single-line JSON the way typos hide in run-on sentences; and when JSON must be embedded inside another string, JSON-in-JSON or in code, the quoting gymnastics are a job for the JSON escaper rather than for hand-placed backslashes. For sharing structure with non-developers, JSON to PDF report and JSON to image turn a payload into something a meeting can look at.
The big-number trap
JSON numbers have no declared precision, and JavaScript reads them as floating point, which is exact only up to 253 (about 9.007 quadrillion). Beyond that, consecutive integers stop being distinguishable: a database ID like 9007199254740993 can arrive as 9007199254740992, no error, one digit quietly wrong. This is why serious APIs ship large IDs as strings, and why “the ID looks slightly off after parsing” is not a mystery but a known boundary. If you control the API, stringify anything that can exceed fifteen digits; if you only consume it, check whether the raw text and the parsed value agree before trusting arithmetic on big identifiers.
Converting: JSON to and from everything
JSON’s hub status means most data jobs are conversions in or out of it, and the toolbox covers the common directions: CSV to JSON for spreadsheet records becoming API payloads, JSON to TSV for the reverse trip into spreadsheets, key and value extraction for pulling one field out of a thousand records, and in-browser editing for the quick surgical change. The one honest caveat in tabular conversion: spreadsheets are flat and JSON nests, so converting nested objects to rows involves flattening decisions (which the tools make visible rather than silently). The wider data-wrangling family lives in the JSON and CSV hub, and the dev toolbox overview in the developer tools pillar.
Frequently asked questions
Is an empty file valid JSON?
No: a JSON document must contain a value. The smallest valid documents are {}, [], "", 0, true, or null; zero bytes is a parse error everywhere.
Why does my API accept JSON my validator rejects?
Many parsers are quietly lenient, accepting trailing commas or comments as extensions. Lenient parsing is a convenience that breaks the moment a strict system enters the pipeline, so validate against the strict standard and lenient systems become a bonus rather than a dependency.
Does key order matter in JSON?
The standard says object keys are unordered, and most systems preserve order anyway as an accident of implementation. Never build logic on key order; anything that needs sequence belongs in an array, which is ordered by contract.
How should dates go in JSON?
JSON has no date type, so dates travel as strings or numbers by convention. ISO 8601 strings are the readable standard; epoch timestamps, covered in the epoch guide, are the compact one. Pick one per API and document it.