How to Format, Validate and Minify JSON

Three jobs, three tools

The three verbs get used interchangeably, but they answer different questions — and only one of them is allowed to change your bytes.

Formatting: making the structure visible

A minified API response is complete and unreadable at the same time. The JSON Formatter parses the payload and reprints it with the indentation you choose, so nesting becomes visible and a diff between two responses finally shows what changed instead of a wall of one line.

• Indentation — 2 spaces for compact reading, 4 for the common house style, 8 or a tab when the file you are pasting into uses them.
• Sort object keys A → Z — recursively, while arrays keep their order, because an array's order is data and a key order never is.
• A live verdict while you type — the moment the text stops parsing, the reported line and column are already on screen.
• Copy or download the result as a named .json file.

Formatting cannot repair invalid input: a payload that does not parse has no structure to print. That is the validator's job.

Validating: the position matters more than the verdict

Every JSON parser agrees on what is valid, but they do not all tell you where validity ends. JSON Validator uses JSON.parse for the verdict — the real standard, not an approximation — and runs a small scanner to locate the first thing that broke parsing, so the answer reads like `line 7, column 3: Trailing comma before the closing brace` rather than an unexplained failure at some unknown offset.

When the payload is valid it reports what it found: root type, how many keys, items or characters, nesting depth, and the top-level key names. That is a quick way to confirm you pasted the payload you meant to, before you build anything on top of it.

Minifying: same meaning, fewer bytes

Minifying parses the payload and prints it again with no whitespace at all: no indentation, no spaces after colons, no line breaks. Nothing is renamed, reordered, rounded or truncated — only formatting changes, which is exactly why it is safe on JSON and unsafe to attempt by hand with a regular expression. The JSON Minifier reports how many characters the operation removed.

Worth knowing before you count on it: on a typical payload minification saves a few percent, while gzip or brotli over the wire saves 70–90%. Strip the whitespace because it costs nothing, but do not expect it to replace compression.

The mistakes behind almost every invalid payload

Most broken JSON is one of a handful of habits, usually imported from JavaScript or Python. The scanner names the construct, not just the character, so each of these comes back with a description and a position.

Escaping deserves a place on the same list. A Windows path written as `"C:\Users\me"` is a broken string, because \U is not a valid escape — write a double backslash for each separator. A newline inside a string has to be `\n`; an actual line break ends the string and the error lands right there.

The invisible failure: a byte-order mark

Some Windows editors and spreadsheet exports save text with a UTF-8 byte-order mark — three bytes at the start of the file that render as nothing at all. Strict parsers reject the document for it, and the reported position is line 1, column 1, pointing at a character you cannot see. If your JSON looks perfect but will not parse and the error sits at the very beginning, that is the cause: re-save the file without a BOM, or delete the first character in the editor.

Where JSON is stricter and looser than JavaScript

• Numbers are doubles. An identifier like `9007199254740993` comes back as `...992`, because JSON numbers are parsed as 64-bit floating point. Keep long integers as strings when the exact value matters.
• Duplicate keys are accepted. `{"a":1,"a":2}` parses, and the last one wins — so a payload can be valid and still ambiguous. Nothing in the syntax prevents it.
• There is no date type. Timestamps travel as ISO strings or epoch numbers, and both sides have to agree on which.
• Key order is not semantic. Two objects with the same pairs in a different order are the same value; only arrays carry meaning in their sequence.

When the data has to leave JSON

A lot of JSON exists to become a spreadsheet, and a lot comes from one. An array of objects maps cleanly to a table: JSON to CSV takes the header row from the keys it finds (in first-seen order), quotes anything containing a comma or a quote, and lets you pick the delimiter, drop the header or add a byte-order mark for Excel — the same three bytes that upset strict JSON parsers elsewhere. In the other direction, CSV to JSON detects the delimiter and the header row and emits one object per record.

The decision point is nesting. A nested object or array has no single column, so either flatten it into its own table or store it as a JSON string inside the cell. Choosing deliberately beats discovering later that the export quietly dropped a level.

A workflow that takes a minute

1. Paste the payload and read the verdict line — parsing is checked as you type.
2. If it is invalid, go to the reported line and column; the message names the construct that broke.
3. Format it with the indentation your project uses, sorting keys if you want stable diffs.
4. Validate once more after any hand edit — a repaired comma is easy to over-repair.
5. Minify a copy for the artefact that ships, and keep the formatted version as the source.

JSON has a cousin in everyday developer work: Base64, another transport encoding that people mistake for protection. Base64 Explained covers that side, including the errors that turn into a corrupt download.