How JSON formatting and validation works

{"name":"toolery","tools":6} and the same data spread across several indented lines mean exactly the same thing. JSON doesn’t care about whitespace or line breaks — formatting only changes how it looks to a human, never what it means to a machine.

What a formatter actually does

A formatter doesn’t just rearrange text. It parses the input into an in-memory structure first — checking along the way that every brace, bracket, and comma is where it should be — then writes that structure back out with consistent indentation. If the parse step fails, that’s where “invalid JSON” errors come from: the formatter has to fully understand the data before it can redisplay it, which is also exactly what makes it useful for validation, not just prettifying.

The mistakes that most often break it

A few patterns account for most JSON errors:

• Trailing commas — {"a": 1, "b": 2,} is valid in a JavaScript object literal, but not in JSON
• Single quotes — JSON requires double quotes around strings and keys, no exceptions
• Unquoted keys — {name: "toolery"} works as JavaScript, not as JSON
• Missing quotes on string values — numbers and booleans don’t need quotes, but text does

Why validation matters beyond appearance

Malformed JSON tends to fail silently in exactly the wrong place — a broken API response, a config file that loads with missing fields instead of throwing an obvious error. Catching the syntax problem up front, with a specific error message, is usually faster than debugging its downstream symptoms later.

Try it yourself in the JSON formatter.