JSON formatting takes a JSON string and re-emits it with consistent indentation and line breaks so it’s readable. Underneath that, every formatter has to parse the input first — which means a working formatter is also a syntax validator. The tool above runs entirely in your browser; no input ever leaves your machine. Paste in compact JSON and it indents it; paste malformed JSON and it shows the parser’s error and position instead. Its Lenient mode also accepts JSON5-style input (comments, trailing commas, single quotes, unquoted keys) and outputs strict JSON.
What “formatting” actually means
There’s no single canonical JSON style, but most pretty-printers converge on a small set of choices:
- Indent. 2 spaces is the de facto default; 4 is also common; tabs are rare. The tool above defaults to 2.
- One member per line inside objects and arrays. Compact JSON puts everything on a single line; pretty JSON puts each
"key": value,on its own line at the appropriate indent depth. - Trailing comma: never. The JSON specification (RFC 8259) does not allow trailing commas, even though many languages do for object literals. A formatter that respects the spec strips them; a strict parser rejects them.
- Key ordering: typically preserved as written (insertion order). Some formatters offer alphabetical key sort as an option for diffing-friendly output.
- String escaping: characters outside printable ASCII may be left as-is (in UTF-8 output) or escaped as
\u00XX(in ASCII-only output).
The output of a formatter is functionally identical to the input — same parsed structure — just visually different.
Common parser errors
Three error classes account for the majority of “why won’t this JSON parse” problems:
- Trailing commas.
{"a": 1, "b": 2,}is not valid JSON. JavaScript object literals tolerate this; JSON does not. Many APIs that accept JSON5 or JavaScript-extended JSON tolerate it; strict JSON.parse() and most server-side parsers don’t. - Single quotes.
{'a': 1}is not valid JSON. JSON strings — both keys and values — must use double quotes. Single-quote tolerance is a JavaScript-specific extension, not part of the JSON spec. - Comments.
{ /* note */ "a": 1 }is not valid JSON. JSON has no comment syntax. JSONC (with-comments) and JSON5 add it; strict JSON does not.
A fourth, less obvious error class:
- BOM bytes. A UTF-8-encoded JSON file with a byte-order mark at the start (
EF BB BF) is technically valid UTF-8 but rejected by some parsers — the BOM appears asat position 0 of the parsed string and the parser sees it as an invalid token before the leading{or[. Strip the BOM before parsing or use a parser that handles it (most modern ones do).
JSON, JSON5, JSONC, NDJSON
These look similar but are not the same:
| Format | Strict JSON-spec compliance | Comments | Trailing commas | Single quotes | Where you’ll see it |
|---|---|---|---|---|---|
| JSON | Yes (RFC 8259) | No | No | No | APIs, config files in many ecosystems, data interchange |
| JSON5 | No | Yes (// and /* */) | Yes | Yes | Some config files (Babel, ESLint configs sometimes) |
| JSONC | No | Yes (// only typically) | Sometimes | No | VS Code config, tsconfig.json |
| NDJSON | Each line is JSON | No | No | No | Log files, streaming APIs, line-delimited records |
If a tool fails to parse a JSON-looking file, identify which dialect it’s actually written in. JSON5/JSONC need a permissive parser; strict JSON needs the file cleaned up.
When formatting matters and when it doesn’t
For API payloads in transit, formatting doesn’t matter — the receiving parser doesn’t care about whitespace, and minified JSON saves bytes. Use a JSON minifier for transit and a formatter for inspection.
For config files in version control, formatting matters a lot — diff readability depends on consistent indentation and one-key-per-line. Pre-commit hooks that auto-format JSON config files prevent diffs that mix formatting changes with content changes.
For debugging API responses, formatting matters for the moment of inspection but the formatted version isn’t kept. The browser DevTools network tab usually pretty-prints automatically; a standalone formatter like this one helps when you’ve copy-pasted compact JSON into a context that doesn’t.
Validation vs formatting
Every formatter parses the input first, which means it implicitly validates. If you only need validation (does this string parse as JSON?), a JSON validator is sufficient — it returns pass/fail and an error position without re-emitting the formatted result.
For schema validation (does this JSON match a specific structure?), formatters and validators alone aren’t enough. JSON Schema (the spec, not just the format name) is a separate validation language; tooling like Ajv or its equivalents in other languages handles “is this object an instance of this schema.” That’s a different problem from “is this valid JSON.”
What the tool above does
The formatter on this page parses the input with the browser’s built-in JSON.parse(), then re-emits with the chosen indent. If parsing fails, it surfaces the error message and (where the parser provides it) the position of the failure. It does not modify keys, values, ordering, or types — only whitespace and structure.
For the inverse direction — taking pretty JSON and stripping all whitespace for transit — see JSON minifier. For pure validation without re-emitting, see JSON validator.