How to Format and Validate JSON: A Practical Guide

May 7, 2026

Someone pastes you a config file, an API response, or a log entry, and it’s all on one line — a wall of curly braces and commas with no spacing at all. You need to actually read it, or worse, something’s broken and you need to find the one character causing it. Doing that by eye is slow and error-prone. Here’s how to get JSON into a shape you can actually work with.

What JSON is, briefly

JSON (JavaScript Object Notation) is a text format for structured data: objects made of key-value pairs, arrays, strings, numbers, booleans, and null. It’s the default way APIs send data back and forth, and it’s used for config files, data exports, and anything that needs to be both human-readable and machine-parseable. The “human-readable” part only holds up when it’s formatted well — which is exactly what breaks first.

Why JSON gets unreadable

Most JSON you encounter in the wild is minified: every unnecessary space, newline, and indent stripped out. Servers do this on purpose, because a smaller payload transfers faster and costs less bandwidth. It’s the right call for a machine reading the data. It’s a bad call for a human trying to read it.

The result is a single dense line where nested objects and arrays all run together. You lose any sense of hierarchy — which key belongs to which object, where one array ends and the next field starts. “Pretty-printing” is the fix: it takes that same data and re-outputs it with consistent indentation and line breaks, so nesting is visible at a glance and you can scan a large structure without losing your place.

Common syntax errors

JSON’s syntax is stricter than JavaScript’s object literals, and that’s usually where things break. A few problems show up constantly:

Trailing commas. {"a": 1, "b": 2,} is valid in some languages but not in JSON — that comma after the last value will fail to parse.
Single quotes. JSON strings and keys require double quotes. {'name': 'value'} looks fine to a person but isn’t valid JSON.
Unquoted keys. {name: "value"} needs to be {"name": "value"} — bare keys aren’t allowed.
Missing or mismatched brackets. An unclosed {, [, or a stray extra one, especially in deeply nested data, is easy to miss by eye and is one of the most common reasons a parse fails.
Comments. JSON has no comment syntax at all — // or /* */ left in from copying a JS file will break parsing.

These are exactly the kind of mistakes that are nearly invisible in a minified blob and obvious once the structure is validated and laid out properly.

Validating and formatting

“Validating” means checking that the text actually conforms to JSON’s grammar — every string quoted correctly, every bracket matched, no trailing commas, no stray characters. A validator won’t tell you if your data is correct in a business sense, but it will tell you definitively whether it’s parseable, and usually points to roughly where the problem is.

In practice, the workflow is simple: paste the JSON in, let the tool validate it, and if there’s an error, fix it at the location flagged. Once it’s valid, pretty-print it so the structure is legible — this is also a good way to spot-check that the data actually looks like what you expected, with the right fields nested in the right places.

Toolio’s JSON Formatter does both right in your browser — your text isn’t uploaded — it validates and flags syntax problems, and formats valid JSON with proper indentation. It’s free, and there’s nothing to install — useful when you just need to check something quickly without spinning up an editor plugin.

Minifying for production

Once you’re done editing and the JSON is correct, the readable, indented version isn’t what you want to actually ship. For an API response, a bundled config, or anything served over a network, minifying strips the extra whitespace back out, cutting the file down to the smallest form that still parses identically. The data is unchanged — only the formatting goes away. This matters more as payloads grow: a large config or dataset with full indentation can be meaningfully larger than the same data minified, and that’s wasted transfer for no benefit once a human doesn’t need to read it directly.

The pattern, then, is to keep the readable version around for editing and debugging, and minify right before it goes into wherever it’s consumed — a build artifact, a deployed config, an API response.

Wrapping up

Formatting and validating JSON isn’t complicated, but doing it by eye on a minified string is a waste of time and an easy way to miss a stray comma or an unclosed bracket. Paste it in, let a validator find the actual problem, pretty-print it while you’re working on it, and minify it again before it ships. That’s really the whole workflow.

Want to know the moment our next game is playable? Get launch updates →