Skip to main content

JSON Formatter

What it does

The JSON Formatter takes any JSON input and produces a formatted, minified, or sort-key-normalised version of it. Pretty-print options cover 2-space, 4-space, and tab indentation; minify collapses everything to a single line; sort-keys reorders object keys alphabetically (recursively, so nested objects sort too) for stable diffs and reproducible test output. When the input is invalid, the tool pins the parse error to the exact line and column rather than just reporting “syntax error somewhere”.

Common situations

You’re debugging an API integration where the response payload is a 40KB compressed JSON blob. The browser dev tools show it as one line; reading nested structures requires either expanding the dev tools’ JSON viewer (which has its own quirks) or pasting elsewhere to format. This tool is the elsewhere.

You’re committing test fixtures to version control and want diffs that survive reordering. Sort-keys produces canonically ordered output where adding or removing a field shows up cleanly in git diff rather than appearing buried in apparent reordering — a reviewability win that compounds across hundreds of fixtures.

You’re investigating a parse error that the consuming language reports as “Unexpected token at position 1247”. Position-as-byte-offset is hard to act on; pasting the JSON here returns “error at line 47, column 23” plus the actual character that caused the failure. The five seconds to translate position to coordinates is faster than every parser you might otherwise use.

You’re producing API documentation that includes example responses. The raw response from the API is dense; the documentation needs the formatted version with consistent 2-space indentation, sorted keys for predictability, and any sensitive values redacted. Format here, redact in your editor, paste into the docs.

You’re reviewing a colleague’s commit that changed a JSON config file. The old version was minified; the new version is formatted differently. Sort-keys both, then diff — the noise from formatting changes disappears, and the actual semantic changes become visible.

What you need to know

The formatter parses input through the browser’s native JSON.parse, the same parser every modern web app uses internally. Successful parsing produces a JavaScript object; the tool then runs JSON.stringify with the configured indent. Sort-keys is implemented as a recursive walk that rebuilds objects with sorted keys before stringifying.

When parsing fails, the JavaScript engine throws a SyntaxError with a position offset embedded in the message (“Unexpected token X at position N”). The tool extracts that offset and converts it to a line and column by counting newlines in the original input up to position N. This is a small detail with disproportionate value — “error at position 1247” is harder to act on than “error at line 47, column 23”.

JSON’s strict syntax means there are several common pitfalls. Trailing commas are not allowed ({ "a": 1, } fails). Comments are not part of standard JSON (no // like this). Single-quoted strings fail; only double quotes are valid. Unquoted property names fail. JSON5 and JSONC (JSON with comments, used by VS Code config files) extend the syntax to allow these, but the standard JSON.parse rejects them. The tool is strict-JSON; for JSON5 input, strip the extensions first.

Numbers in JSON have IEEE 754 double-precision limits. Numbers above 2⁵³ (about 9 quadrillion) lose precision through the parse-stringify round trip — relevant when handling very large IDs that arrive as numeric strings from APIs aware of this. Distrust large unquoted numeric IDs in JSON; the canonical fix is for the API to send them as strings.

Sort-keys is non-destructive to your source — only the output is sorted. The original key order in your file is unchanged. Useful for “what would this look like normalised?” without committing the change.

For very large inputs (above a few megabytes), the formatter may visibly delay. Browser parse and stringify are fast but not constant-time; for genuinely large fixtures, prefer a CLI tool like jq (jq . input.json > output.json formats; jq -S sorts keys).

Frequently asked questions

How do I format JSON?

Paste it into the tool, pick an indent level (2 spaces is the most common standard), copy the formatted output. The browser’s native JSON parser handles the work; the formatter just adds the indentation back.

What’s the difference between minify and pretty-print?

Pretty-print adds whitespace (newlines and indentation) to make the structure readable. Minify removes all whitespace, producing the smallest representation. Both produce semantically identical JSON; the choice is about readability vs file size.

Why does sort-keys matter?

Reproducibility. Two JSON files with the same keys in different orders are semantically identical but textually different — git diff shows them as completely changed. Sort-keys before committing means your diffs reflect actual content changes, not key-order shuffling.

Can JSON have comments?

Standard JSON: no. JSON5 and JSONC (a variant used by VS Code, TypeScript config, etc.) allow // and /* */ comments. The tool is strict — comments produce parse errors. For JSONC input, strip comments first.

What’s the difference between JSON, JSON5, and JSONC?

Strict JSON (RFC 8259) has the rules above. JSON5 extends to allow comments, trailing commas, single quotes, and unquoted keys. JSONC is somewhere between — comments and trailing commas allowed, single quotes and unquoted keys not. Use strict JSON for interoperability; use JSON5/JSONC for human-edited config files.

Why are large numbers losing precision?

JSON numbers are doubles (IEEE 754 64-bit floating-point). Integer values above 2⁵³ (about 9 × 10¹⁵) cannot be represented exactly. When an API returns a 19-digit ID as an unquoted number, the parsed value rounds to the nearest representable double — silently changing the ID. APIs aware of this send large IDs as strings.

Can I format JSON in VS Code?

Yes — Cmd/Ctrl+Shift+P → “Format Document” formats the active file using its JSON formatter. For one-off formatting outside the editor, this tool is faster than opening VS Code.

What’s the most common JSON parse error?

Trailing commas. JavaScript and Python both allow them in object literals; standard JSON does not. Most “unexpected token” errors trace to a stray comma after the last key in an object or last item in an array.

Common problems

Problem: “Unexpected token o” or similar at position 0.

You’re trying to parse something that is not JSON. The error happens because the parser saw “o” as the second character (often “[object Object]”, which is the result of accidentally stringifying a JS object with the default toString). Make sure you’re pasting actual JSON, not the result of calling String() on an object.

Problem: The formatter does nothing — no error, no output.

Empty input produces empty output. Or your input is white-space only. Confirm the input field actually contains the JSON you expect.

Problem: Sorted output looks subtly different from the original.

Sort-keys is recursive — nested objects sort too. If the apparent re-arrangement extends deep into the structure, that is expected. Only the keys change order; the values are unchanged.

Problem: Numbers in the formatted output have decimal points where the source had integers.

This is a stringify quirk — JSON.stringify(1.0) outputs 1, not 1.0. If your source explicitly had 1.0, it was already implicitly the same as 1 to JSON. There is no way in JSON to distinguish “integer 1” from “float 1.0” — they share representation.

Problem: The tool freezes on a very large input.

JSON parse and stringify scale with input size. Files above ~10MB can produce visible delays or freezes. For genuinely large inputs, use a CLI tool (jq) which handles streaming better.

Quick guides

For VS Code users: Cmd/Ctrl+Shift+P → “Format Document”. Works on any open .json file. For sort-keys, install the “Sort JSON objects” extension or use a jq task in your terminal.

Command-line jq: jq . input.json formats; jq -S input.json sorts keys; jq -c input.json minifies. Pipe-friendly for shell scripts and CI checks.

Browser DevTools: Network tab → click a request → Response tab → Pretty-Print button (the { } icon at the bottom). Useful for in-context formatting; this tool is faster for ad-hoc work outside DevTools.

Tips

  • The “min” output is the cleanest minified form your build tools produce. Use it when committing JSON to version control where size matters; use a formatted version locally where readability matters.
  • Sort-keys is non-destructive — original key order in your source file is unchanged, only the output is sorted. Useful for “what does this look like normalised?” without committing the change.
  • JSONC (JSON with comments) and JSON5 are not supported. The browser’s JSON parser is strict — comments and trailing commas throw errors. For those formats, strip them first or use a different parser.
  • Very large inputs (above a few megabytes) may visibly delay the formatter. The browser’s parse and stringify are fast but not constant-time; for genuinely large fixtures, prefer a CLI tool like jq.
  • Numbers in JSON have IEEE 754 double-precision limits. Numbers above 2⁵³ lose precision through the parse-stringify round trip — relevant when handling IDs that arrive as numeric strings from APIs that know this.
  • Treat formatted JSON as the canonical form in version control. Minify only when shipping over the wire.

Related tools in this suite

The natural pairing is the Mock JSON Generator — generate test fixtures there, format them here. The Text Diff tool is the right next stop when comparing two JSON snapshots — sort-keys both first, then diff, and the result is meaningful.

Take it further

JSON formatting is solved at the file level. The harder operational problem is JSON consistency across a system — ensuring the API and the consuming services agree on the shape, that test fixtures match production, that schemas don’t drift. The systems we build often include schema validation as part of API design (JSON Schema, OpenAPI), which removes “wait, why does this field exist on staging but not production?” investigations.