JSON prettifier
What the JSON prettifier does in your workflow
This JSON prettifier sits between the thing that produced the JSON and the thing you are about to do with it. A response comes back minified, a config file arrives with no formatting, a payload gets copied out of a log line. You paste it, it comes back indented two spaces per level with one value per line, and you carry on.
It is local. The parse and the reindent both happen in the browser tab, so pasting a response that contains a bearer token or a customer record does not put that data on anyone's server. There is no signup and no run limit to plan around.
The three steps
How to use the JSON prettifier in three steps
The whole loop takes a few seconds and does not interrupt whatever you were doing.
- Step 1
- Paste the JSON in, minified or half-indented, it does not matter which.
- Step 2
- Press Format. The tool parses it and reindents at two spaces, on your device.
- Step 3
- Copy the output straight into your editor, your ticket or your diff.
Debugging
Using a JSON formatter in a debugging loop
The common case is not admiring the formatting, it is answering one question fast: what did the API actually send back? A minified response hides that. Indented, you can see in a second whether the field you expected is present, whether it came back null, and whether the array has one element or four hundred.
Because there is no run limit, this works as a repeated step rather than a one-off. Call, paste, read, change something, call again. Nothing throttles you on the tenth pass.
- Check shape first
- Indentation tells you the nesting depth before you read a single value.
- Then check presence
- A missing key is obvious in a formatted object and invisible in a minified one.
- Then check types
- Quotes around a number are easy to spot once each value sits on its own line.
Code review
Why pretty-printed JSON gives a cleaner diff
Git and every code review tool built on it compare files line by line. A minified JSON file is one line, so changing one value anywhere in it marks the whole line as changed and tells a reviewer nothing about what moved.
Formatted, one key per line, the same change produces a diff showing exactly the line that differs. This is why JSON fixtures, configuration and committed API samples are almost always kept indented in a repository, even though the minified version is smaller. Run the file through here before you commit it and every future review of that file gets easier.
When it refuses
What to do when the JSON formatter says Invalid JSON
A rejection means the parser could not read the text as JSON. The app does not guess and does not repair, so the fix is to find the character JSON does not allow and remove it.
Work down this list in order. One of them is nearly always the culprit, particularly when the text came out of a JavaScript file or a config format that only looks like JSON.
- Trailing comma
- A comma after the final entry in an object or array. JavaScript permits it, JSON does not.
- Single quotes
- Keys and strings both need double quotes in JSON.
- Unquoted keys
- A bare key is a JavaScript object literal, not JSON.
- Comments
- Config files often carry them. JSON has no comment syntax at all.
- NaN or undefined
- Not JSON values. Serialise them as null or a string before they reach the payload.
- Extra text around it
- A log timestamp, a prompt, or a stray bracket copied along with the payload.
What you can and cannot change
Two spaces, fixed, and what that means for your workflow
The indent is two spaces per level with no option to change it. That matches the JavaScript and TypeScript default, and it matches what most JSON you receive already uses, so in practice the output usually drops straight into place.
If your project standardises on four spaces or tabs, paste the result into your editor and let the editor's formatter take the last step. Key order is preserved exactly as it arrived, so there is no alphabetical sort to undo either.
Straight answer
Does formatting JSON mean the data is correct?
No, and it is worth being clear about it. The only thing a successful format proves is that the syntax parses. A file can be perfectly indented and still carry the wrong value, a missing field, or a date stored as a string where a number belonged.
What formatting buys you is a surface a person can actually review, which makes those mistakes much easier to notice. The noticing is still yours to do. There is no schema check here and no validation beyond the parse.
Who it's for
Who reaches for a JSON prettifier, and when
Backend and frontend developers mid-debug, checking what an endpoint really returned. Reviewers tidying a fixture before it lands in a repository. QA and support staff reading a payload pasted into a bug report, trying to work out which field went wrong.
Also anyone outside engineering who has been handed an export and told the answer is in there somewhere. Formatted, a JSON file is browsable. Minified, it is a wall.