JSON formatter: pretty-print, minify, and locate syntax errors

When formatting actually helps

An API response arrives as one long line and the nesting is impossible to follow. Expanding it shows immediately whether a field sits in an object or inside an array element.

Pre-submit checks are the second case: trailing commas, unquoted keys, unescaped newlines inside strings, and mismatched brackets are all things a human can spot but only a parser can settle. Letting JSON.parse report a position beats scanning by eye.

The reverse direction matters too: minifying a debug payload to one line so it fits in an environment variable, a command-line argument, or a single-line config value.

• Expand a one-line API response
• Check syntax before submitting
• Minify for an environment variable or single-line config
• Compare the structure of two versions

How to avoid the usual mistakes

Beautifying is JSON.parse followed by JSON.stringify with two-space indentation. The output is the parsed result, not the original layout: key order may change and the whitespace is regenerated.

The position in an error message is the character offset reported by the browser's JSON.parse, zero-based in Chrome and Edge, usually with a line and column as well. It marks where the parser stopped, which is not always the character at fault: a missing comma often surfaces at the next key, and a trailing comma at the closing bracket. Read a few lines before the reported position.

JSON is strict: comments, single quotes, trailing commas, NaN, and undefined are all invalid and fail immediately. A config with comments is JSONC; do not run it through a JSON tool expecting it to be cleaned up. Use a JSON5 or JSONC parser when you need the looser syntax.

Large integers lose precision. JSON.parse converts every number to an IEEE-754 double, so integers above 2^53−1 (9007199254740991) are no longer exact: 1234567890123456789 is formatted as 1234567890123456800. This is a limit of JSON.parse, not of formatting. Store order numbers and snowflake IDs as strings at the source.

Watch memory on large files. Hundreds of kilobytes to a few megabytes are usually instant; a file of tens of megabytes can visibly stall, and may fail on low-memory devices, because the original text, the parsed object, and the serialized output all live in memory at once. Nothing is uploaded, and a stuck tab recovers on refresh.

• Indentation is two spaces; output is the parsed result
• Position is zero-based; read a few lines before it
• Comments, single quotes, and trailing commas always fail
• Integers above 2^53−1 change; store IDs as strings

Alternatives and limits

The command-line jq is better for large files and batch work: it streams, uses far less memory, and can select fields, filter, and transform. The cost is installing it and learning the syntax.

When you only need one field, searching the response in devtools (Network → Response) is faster than copying the whole payload out.

For exact big integers, use a parser that supports BigInt or keep the value as a string; for comments and trailing commas, use JSON5 or JSONC; for structural validation, use JSON Schema.

This tool does not validate against a schema and does not preserve the original number text. It pretty-prints, minifies, and locates syntax errors — nothing more.

• Large files and batch work → jq
• One field only → devtools response view
• Big integers → BigInt parser or strings
• Comments → JSON5 or JSONC