How to Format JSON Without Sending It to a Server

Minified JSON is what servers like to send and what humans hate to read. One missing comma is enough to waste an afternoon, and the usual fix is not a new framework. It is indentation, plus a parser that tells you where the text stopped being JSON.

I do this on JSON Formatter because the parse happens in the browser. A response body that contains a customer id or a test token does not need to be uploaded to find a trailing comma.

What formatting actually changes

Formatting does not sort keys, drop nulls, or "fix" your data. It prints the same values with line breaks and indents. If a number was a string, it is still a string. If an array was empty, it is still empty. That is a feature. A tool that rewrites your payload while pretending to pretty-print it is a tool that will eventually hide a bug.

Validation is the other half. JSON is stricter than JavaScript. Keys must be in double quotes. Trailing commas are illegal. Comments are illegal. Single quotes are illegal. A file that "works" in a loose config loader can still be rejected by JSON.parse.

A reliable order of work

1. Copy the exact body from the network panel, the log line, or the file. Do not retype it. Retyping is how you fix the bug by accident and then cannot reproduce it.
2. Paste it into the formatter and run it.
3. If it formats, you are done with syntax. Use the JSON Viewer if the document is deep and you only care about one branch.
4. If it fails, read the position. Look at the previous line, not only the line the parser names. The parser often notices the problem one token later.
5. Fix one error and format again. Do not "clean up" five things at once or you will not know which edit mattered.

The errors that show up every week

Trailing comma. {"a": 1,} is comfortable in JavaScript and invalid in JSON. Delete the comma after the last property or the last array item.

Single quotes. JSON strings use ". If you pasted a Python dict, replace the quotes and change True, False, and None to true, false, and null.

A comment left in a config. // timeout is not JSON. Move the note into the README or into a field the schema allows.

Smart quotes. A message copied from a document sometimes replaces straight quotes with curly ones. They look almost right and they fail the parse. Retype the quotes.

Truncation. A log system cut the line at 2,000 characters. No formatter can close the braces you do not have. Fetch the full body.

A leading BOM or a stray sentence. Some exports start with a byte-order mark or with "response:" before the {. Delete everything before the first brace or bracket.

When the JSON is valid and still wrong

Syntax is not meaning. A 200 response can contain {"error": "card declined"} and be perfectly valid JSON. Formatting helps you see that field. It does not tell you whether the business rule is correct.

Watch types. An id that arrives as "1042" will not equal the number 1042 in a strict client. The viewer makes the quotes obvious. Also watch missing keys. A tree that simply does not show email is clearer than a wall of text you searched badly.

Pretty in git, compact on the wire

I keep pretty JSON in repositories when humans review it: fixtures, a small config, an example in a docs page. I minify when the string has to live in one environment variable or one log line. JSON Minify is the reverse step, after the pretty copy is the one you trust.

Do not pretty-print a secret into a screenshot for a ticket if the ticket is public. Replace the token with "redacted" first, then format the rest.

A small habit that saves the next person

When you paste a payload into a bug report, paste the formatted version and say whether the formatter accepted it. "Invalid at the trailing comma after items" is a better report than a 4 KB line and the words "api broken". If you are teaching someone, give them one broken example from this list and let them fix it. The rule sticks when they have seen the parser complain.

The formatter will not design your API. It will stop you debugging a comma as if it were a server outage. That is enough to earn a bookmark.

What I do with the result

I copy the formatted JSON into the ticket or the docs, then I minify only the copy that has to travel. If the pretty version and the one-line version disagree, I did not finish the edit. JSON Formatter, the viewer, and the minifier are three steps of one job: read it, point at the field, ship the compact form. None of them need the payload on a server.