JSON Formatter

Format, validate, and minify JSON instantly. Errors highlighted with line and column.

Input

Output

Enter input above to see the result.

Why JSON breaks

JSON travels minified — every byte counts when an API response is being shipped. But minified JSON is unreadable, and hand-edited JSON is almost always invalid on the first try. This tool round-trips through the browser's native JSON.parse / JSON.stringify to produce indented, copy-able output, validate the structure, or strip whitespace back out. Nothing is uploaded; everything happens in the page.

The five syntax errors that catch everyone

Trailing commas. Legal in JavaScript, fatal in JSON. The parser points at the closing } or ], but the real fault is the comma one token earlier.
Single quotes instead of double. JSON demands "key", never 'key'. Object literals from JS, Python dicts pasted raw, and YAML snippets all trip this.
Smart quotes from copy-paste. Word processors and chat apps silently replace " with “ / ”. Those aren't valid JSON delimiters.
Comments. If your "JSON" has // or /* */, it's JSONC (VS Code config, tsconfig.json) — strip those before parsing.
Unquoted keys. {name: "Alice"} is JavaScript. JSON requires {"name": "Alice"}.

Format, validate, or minify — which button to reach for

Format — paste a minified API response and get back something a human can scan, with consistent two-space (or four-space) indentation.
Validate — confirm your hand-written JSON is structurally sound before piping it into another tool, with the exact line/column the parser tripped on.
Minify — strip whitespace before pasting JSON into a context where size matters (URL params, env vars, config files, HTTP payloads).

Integer precision and the silent round-trip bug

JavaScript's JSON.parse converts every number to a 64-bit float. Numbers larger than 2⁵³−1 (9,007,199,254,740,991) lose precision silently — common with database IDs, Snowflake IDs, and timestamp-in-nanoseconds values. If your wire protocol uses 64-bit integers, transport them as strings. There's no warning when this fails; you just get the wrong number back.

JSON's lookalikes: JSONC, JSON5, NDJSON

Three dialects look identical but fail strict validation: JSONC (JSON with comments — VS Code config files, tsconfig.json), JSON5 (relaxed syntax with trailing commas, single quotes, unquoted keys, comments — common in tooling configs), and NDJSON / JSONL (one JSON object per line with no surrounding array — common in log pipelines and streaming exports). If your input fails to parse and looks mostly-valid, check which dialect you actually have.

Indentation, file size, and diff hygiene

Size is not cosmetic. A 50KB pretty-printed JSON becomes roughly 80KB at 4-space and 30KB minified — meaningful when you're transporting config or caching responses. Rule of thumb: minify for HTTP, indent for human review and version control, never both formats in the same canonical store.
Unicode escape inconsistency. JSON spec allows escape sequences like é but also raw UTF-8 bytes. Both parse correctly; both display as "é". When diffing JSON files, inconsistent escape style produces noisy diffs even though the content is identical. Either run through a canonical formatter on every commit, or accept the noise.
Browser native usually wins on speed. Libraries like big-json and json5 exist for specific use cases, but for routine parse/stringify on reasonable input sizes, the V8/SpiderMonkey native implementations beat any JS library by an order of magnitude. This tool uses native by design.

Trailing comma, line 1, col 57

Paste the minified line {"user":{"id":42,"roles":["admin","editor"],"active":true}} and hit Format: it re-emits the same object indented two spaces across seven lines, and the meta line reports the character and line count. Hit Minify and it round-trips straight back to the 58-character original. Now add a trailing comma — …"active":true,} — and Validate fails with ✗ Unexpected token } … line 1, col 57: the tool takes the parser's raw character position and converts it to a line and column for you.

Questions people actually ask

Why does every error say "line 1"? Because minified JSON is one line — the line/column is computed from the character offset, so a single-line document puts everything on line 1. Format the JSON first, then re-validate, and the reported line will actually point at the offending row.

Format (2) or Format (4) — does it matter? Only for size and house style; both are valid JSON. Four-space indent is easier to scan but noticeably larger — a 50 KB payload is roughly 80 KB at four-space and 30 KB minified. Pick one indent and stay consistent so diffs stay clean.

Can minifying change my numbers? Yes, silently. The round-trip goes through JSON.parse, which stores every number as a 64-bit float, so an integer above 9,007,199,254,740,991 (2⁵³−1) — a Twitter/Snowflake ID, a nanosecond timestamp — comes back subtly wrong. Transport those as quoted strings.

My JSON looks fine but won't parse. It's almost always one of four things: single quotes instead of double, a trailing comma, // or /* */ comments (that's JSONC, not JSON), or smart quotes pasted in from a word processor. None are legal JSON.

Parse tree in, whitespace out

Formatting parses the text into a real data tree and re-serialises it with consistent indentation — which is why a formatter that rejects your input has just found a genuine syntax error, not been fussy. JSON's grammar is deliberately tiny: double-quoted keys, no trailing commas, no comments, and only four scalar types. Pretty-printing walks the parsed tree and adds two-space (or four-space) indentation per nesting level; minifying does the reverse, stripping all insignificant whitespace. Because both go through a real parse, the output is guaranteed well-formed even when the input's spacing was chaotic — the round-trip is the validation.

The upstream-token trap

The errors that break JSON are almost always the four things JSON forbids that other formats allow: a trailing comma after the last array or object element, single quotes instead of double, unquoted keys, and JavaScript-style // comments. All are legal in a JS object literal and all are invalid JSON. When a parser points at a line, look one token before it — the real fault is usually the character just upstream of where it gave up.

Decode the messages parsers give you: reading JSON error messages.