JSON is simple enough to write by hand, which is exactly why it's so easy to end up with a wall of unindented text that's technically valid but painful to read. A few small conventions make the difference between a payload you can scan in two seconds and one you have to fight with.
Pick an indentation width and stick to it
Two spaces is the de facto standard across the JavaScript/JSON ecosystem — it's whatJSON.stringify(value, null, 2) produces, and what most formatters default to. Four spaces reads a little more clearly for deeply nested structures, but costs more horizontal space. Tabs work too, though they render inconsistently between editors, so most teams avoid them for JSON specifically. The exact width matters less than consistency — mixing widths in the same file or across a team's config files makes diffs noisy for no reason.
Trailing commas and comments aren't valid JSON
This trips people up constantly, usually because JavaScript object literals are more permissive than JSON. The JSON spec does not allow:
- Trailing commas —
{"a": 1, "b": 2,}is invalid; the comma after2has to go. - Comments — no
//or/* */, in any position. If you need annotated config, that's a sign you want JSON5, JSONC, YAML, or a format that explicitly supports comments instead. - Single-quoted strings — keys and string values must use double quotes.
- Unquoted keys — every key needs quotes, unlike a JS object literal.
A strict parser rejects all of the above with a syntax error, usually pointing at a line and column. Paste suspect JSON into our JSON Validator to get that exact error location before you spend time hunting for the problem by eye.
Should keys be sorted?
Parsers don't care about key order — {"a":1,"b":2} and {"b":2,"a":1} are equivalent as data. But order still matters for humans: a consistent order (alphabetical, or grouped by relevance — IDs first, then core fields, then metadata) makes two versions of a similar object easier to compare at a glance. This matters most for checked-in config files and fixtures that get diffed in code review. If you're comparing two JSON documents to see what actually changed, don't rely on eyeballing a diff — our JSON Diff tool compares by path and ignores key order and formatting, so it only shows you real differences.
Pretty-printed vs. minified: use both, for different jobs
These aren't competing conventions — they're the same data formatted for two different audiences:
- Pretty-printed (indented, one field per line) is for humans: config files you'll read and edit, API responses you're debugging, anything that gets reviewed in a diff.
- Minified (no whitespace at all) is for machines: API payloads over the wire, bundled data files, anything where every byte counts and no one is reading it directly.
Our JSON Formatter handles the human-readable direction — paste messy or minified JSON and get clean, indented output with syntax error detection. When you need to go the other way for production, the JSON Minifier strips whitespace and shows you exactly how many bytes you saved.
A quick checklist
- Validate first — don't try to format something that isn't valid JSON yet.
- Pick 2-space or 4-space indentation and use it everywhere in the project.
- No trailing commas, no comments, no unquoted keys — even if your language's object literal syntax allows it.
- Keep a consistent key order in files that get diffed regularly.
- Pretty-print for anything a human reads; minify for anything only a machine reads.
Try it yourself
Paste any JSON into our JSON Formatter to instantly clean it up, with line-accurate error messages if something's off. Like every tool on this site, formatting happens entirely in your browser — nothing is uploaded anywhere.