JSON Formatter & Validator

JSON formatter: readable data, fewer production bugs

JSON is the lingua franca of modern APIs. Pretty-printing exposes missing commas, mismatched braces, and accidental trailing text. Minifying removes whitespace for bandwidth while keeping payloads valid for clients that reject pretty output.

When to validate here: pasting sample responses from logs, preparing fixtures for tests, or teaching newcomers how objects and arrays nest. The linter feedback is immediate and private—nothing uploads to a server in normal browser-only operation.

Privacy tip: large JSON may contain tokens or PII — scrub secrets before sharing screenshots. Pair with Base64 or URL tools when debugging encoding layers.

Edge cases: duplicate keys are technically invalid per RFC but some parsers last-wins; JSON cannot have comments unless your pipeline uses JSON5—don’t assume comments are portable.

Workflow: format → visually scan structure → minify only when sending over the wire. Keep canonical pretty copies in repos for code review readability.

What Format and Minify actually do

Both buttons parse your input with the browser’s built-in JSON parser and write it back out — with 1, 2 or 4 spaces of indentation for Format, or with no whitespace at all for Minify. If the input is not valid JSON, nothing is rewritten and the parser’s error message is shown instead. Because the output is regenerated from the parsed data rather than edited in place, a few things change in ways worth knowing:

• Duplicate keys: {"k":1,"k":2} becomes {"k":2}. The last value wins silently and the earlier one is dropped — a common source of “my setting is ignored” bugs.
• Big integers lose precision: 12345678901234567890 becomes 12345678901234567000, because numbers are stored as 64-bit floating point and only integers up to 9,007,199,254,740,991 are exact. Send large IDs as strings.
• Number spelling is normalised: 1.0 becomes 1 and 1e3 becomes 1000 — the same values, written differently.
• Integer-like keys move first: {"b":1,"2":0,"a":2,"1":0} comes out as {"1":0,"2":0,"b":1,"a":2}. Other keys keep their original order.
• Escapes are decoded: "caf\u00e9" is written back as "café".

Worked example: fixing invalid JSON

This looks like JSON but is rejected:

{
  'name': "Ada",
  "langs": ["en", "fr",],
  "active": True
}

Three problems: property names and strings need double quotes, a comma is not allowed after the last item in an array or object, and the literals true, false and null must be lowercase. The corrected version formats cleanly, and minified it becomes {"name":"Ada","langs":["en","fr"],"active":true} — 48 characters instead of 74 with 2-space indentation.

Minifying saves more as nesting grows: a three-user sample with ids, names, roles and an active flag goes from 412 characters pretty-printed to 203 minified. Over HTTP, gzip or Brotli compression narrows that gap considerably, so readable JSON in config files and fixtures costs very little.

Reading the error message

Error messages come from your browser, so the wording varies, but current Chrome and Edge report a position and a line and column, for example “Expected property name or '}' in JSON at position 4 (line 2 column 3)”. Position counts characters from zero. The real mistake is usually at that point or just before it — often a missing comma or quote on the previous line.

“Unexpected non-whitespace character after JSON” means there is more than one value in the input, such as two objects one after another. That is how NDJSON (newline-delimited JSON) log files are written; format one line at a time.

JSON, JSONC, JSON5 and NDJSON

• JSON (RFC 8259): what this tool accepts — no comments, no trailing commas, double quotes only.
• JSONC: JSON with // and /* */ comments, used by tsconfig.json and VS Code settings. Remove the comments before validating here.
• JSON5: a looser superset allowing single quotes, unquoted keys, trailing commas and hexadecimal numbers. Fine for hand-edited config if your tooling supports it; not interchangeable with JSON APIs.
• NDJSON / JSON Lines: one complete JSON value per line, common for logs and data exports. Each line is valid JSON on its own; the file as a whole is not.

Choosing an indentation

Two spaces is the convention in JavaScript projects (package.json, most API documentation) and keeps deep nesting readable on narrow screens. Four spaces matches Python’s json.dumps(indent=4) and many Java style guides. One space is a compromise for files that are diffed often but still read by humans. Pick one per repository and let your formatter enforce it, so reviews show real changes rather than whitespace.