JSON Beautifier

Beautifying is re-serialization

Nothing here edits your text. The document is parsed into values and written out again from scratch, which is why the result is always consistent — and why a few things you may have cared about do not survive the trip.

If the input will not parse, nothing is produced at all — you get the error and its position instead. That is usually the faster path anyway: the validator explains exactly what is wrong.

Choosing an indentation

Four options, and the choice is mostly about who reads the file. Here is what each costs on the same 25-record document.

Two spaces is the de facto standard for JSON and what almost every tool emits by default — package.json, composer.json, most API responses when they are pretty-printed. Tabs are the compact choice and let each reader pick their own visual width. Eight spaces exists mainly for deeply nested documents where you genuinely need the structure to shout; it gets expensive fast.

Sorting keys, and the order you actually get

Sorting is recursive over objects. Arrays are never reordered — their order is data, and changing it would change what the document means.

The sort is by string comparison, which is not quite alphabetical, and the difference surprises people:

{ "b": 1, "A": 2, "a": 3, "_x": 4, "10": 5, "2": 6, "Z": 7 }

{ "2": 6, "10": 5, "A": 2, "Z": 7, "_x": 4, "a": 3, "b": 1 }

Two things happened. Keys that look like integers came first, in numeric order — that is a JavaScript object rule, not a sorting choice, and "2" before "10" is the one part of this that matches intuition. The rest sorted by character code, which puts every uppercase letter before _, and _ before every lowercase letter. So Z sorts before _x, and _x before a.

This is worth knowing before you sort a file that other people will review, because "alphabetical" is not what they will see.

When to sort and when to leave it

• Sort when you are comparing two documents by eye and the key order differs. Sorting both makes a text diff usable. (A structural diff does this for you without touching the files.)
• Sort when generating a file that is checked into a repository and regenerated often — a stable order keeps the diffs small.
• Do not sort package.json, tsconfig.json, or anything where convention puts name and version at the top. Sorting moves them into the middle and every reviewer notices.
• Do not sort a file whose key order is documentation — configuration where related settings are deliberately grouped.

Sorting never changes what a parser sees. The risk is entirely social: a sorted file is a large diff, and a large diff hides the one line you actually changed.

Files that are nearly JSON

A lot of what people try to beautify is not JSON. tsconfig.json, .eslintrc.json and VS Code settings allow comments and trailing commas — that dialect is JSONC, and a strict parser rejects it by design.

1. Strip comments and trailing commas, beautify, then put the comments back — workable for a one-off, tedious as a habit.
2. Use a JSONC-aware formatter such as Prettier, which understands the dialect and preserves comments.
3. Keep the file as-is and use this page only for the JSON parts you copy out of it.

The same applies to NDJSON and JSON Lines, where each line is a separate document. Beautify one line at a time, or the parse will fail on the second one.

Beautifier, formatter, prettifier

They are the same operation under different names, and this page and the JSON formatter share one implementation. The formatter page carries the deeper reference material on what re-serialization changes and how to handle very large documents; this page exists because "beautify" is what many people search for, and it should lead somewhere that answers the question.