JSON Formatter Online: Format, Validate and Minify in Your Browser

By shabbychef · San Francisco, CA

A minified API response is one long line of text. Somewhere inside it is the field you need, and right now it is invisible. That is the moment a JSON formatter earns its place in your workflow: paste the payload, get indentation, colours and a straight answer about whether the document is even valid.

This formatter runs in your browser, next to the code you are debugging. Paste JSON, choose Format, and the same tool can validate the syntax, minify the document, sort every key alphabetically, or point at the line where the parser gave up.

What a browser JSON formatter actually does

Every formatter is a thin layer over two functions that already exist in your browser: JSON.parse and JSON.stringify. The formatter hands your text to the parser, and the parser either builds an object or throws. When it throws, there is no object, no output and no partial result, which is why an online tool can tell you "invalid" with such confidence.

If parsing succeeds, the second step reprints the object as text. With an indent argument, stringify writes the document across multiple lines with consistent spacing. Without one, it writes the same value back as a single compact line. That round trip is what people mean by beautify, pretty print and format: the value never changes, only the whitespace between tokens.

The three modes map directly onto those two calls. Format parses and reprints with indentation, so a nested object becomes a readable tree. Minify parses and reprints with no spaces at all, which is what you want for a payload you are about to ship. Validate parses and stops, leaving your original text untouched while reporting the position of the first error.

Around that core, the useful features are small conveniences: a switch for 2-space or 4-space indentation, a sort-keys toggle, counters for characters and object keys, a sample document to test against, and a copy button for the result. None of it needs a server, and none of it needs an account.

The strict rules hiding behind every parse error

JSON is defined by RFC 8259 and ECMA-404, and the grammar is deliberately tiny. Strings and object keys use double quotes and nothing else. Property names are always quoted, even when they look like ordinary identifiers. The only literals are true, false and null, all lowercase, and numbers use a plain decimal form with no leading zeros, no hexadecimal and no NaN.

When you come from JavaScript or Python, the differences are what bite. A JavaScript object literal tolerates trailing commas, single quotes and unquoted keys because the engine is parsing code, not data. JSON has no such tolerance. The parser is not being pedantic on purpose: the format was designed so that a small, unambiguous grammar could be implemented identically in every language, and so that data could be exchanged between systems that share nothing else.

That design also means there is no comments syntax. Neither // line comments nor /* block comments */ survive a strict parse, which is why editors invented JSONC for files like tsconfig.json and why a build step has to strip comments before a real parser sees the file.

The grammar has one more consequence worth remembering: error positions are frequently misleading. The parser reports where it gave up, not where you made the mistake, and those two places can sit hundreds of characters apart in a nested document.

Eight mistakes that break real payloads

Almost every failed parse in the wild comes back to the same short list. The table below pairs each cause with the fix.

Two details are worth calling out. An unescaped double quote does not just break the string it sits in: the parser treats the quote as the end of the value, so everything after it is read as structure and the error lands much further down. And when the reported position is past the end of the file, the document is truncated, so the fix is an unclosed bracket or an unfinished string rather than whatever looks broken at the cursor.

Pretty print or minify: what whitespace actually costs

Formatting and minifying are the same transformation run in opposite directions, and both are lossless. Whitespace outside string values carries no meaning in JSON, so a beautified document and its minified form parse to exactly the same value. Nothing is renamed, nothing is rounded, and nothing inside a quoted string is touched, which is a point worth trusting only if you can see it: format a payload, minify it, and compare the two against the original.

The cost side is simple arithmetic. Every indentation level adds one character per level per line, so a 4-space indent on a document nested four levels deep spends roughly sixteen characters per line on empty space. On a ten-thousand-line payload that is hundreds of kilobytes of spaces, and it is the reason production endpoints send compact JSON while editors keep a formatted copy.

Where does that leave you? Format when a human has to read the data: debugging, code review, documentation samples, and configuration files that someone will edit by hand. Minify when a machine is the consumer: HTTP responses, request bodies, values stored in localStorage, and fixtures embedded in test files. If the transport is compressed, remember that gzip or Brotli already collapses runs of repeated whitespace, so minifying on top of compression buys much less than it does in a log file or a database row.

Indentation style is a team convention, not a standard. Two spaces is the default in most JavaScript projects and in tools like Prettier. Four spaces is common in Python and Java codebases, where json.dumps(data, indent=4) is the familiar call. The specification mandates none of it, so pick what matches the project and keep it consistent.

Sorting keys, stable diffs and readable reviews

Sorting keys looks cosmetic until you compare two versions of the same payload. The same object written by a JavaScript service and a Python worker can arrive with its keys in different orders, so an unsorted diff shows changes on lines that never actually changed. Sorting alphabetically at every level, the same thing jq -S or sort_keys=True does, makes the two documents line up and lets a reviewer see the one field that moved.

The sort-keys toggle in this formatter is deep: it walks nested objects and arrays, so inner objects are ordered as well. Two caveats are worth knowing. Sorting changes the order of the keys in the text, and some systems care about insertion order, so do not sort a document you are about to feed into something order-sensitive. Sorting does not touch arrays, because array order is data rather than presentation. And if a document has duplicate keys, different parsers keep different ones, so a formatter cannot repair that for you.

Debugging an API response with the formatter

The workflow I use for a failing integration has four steps, and the formatter sits in the middle of all of them.

First, paste the raw response into the input panel and press Validate. If the payload is truncated in the logs, this is where you find out, because the error position lands past the end of the text. Second, press Format with your usual indent and watch the structure appear. Nested objects that were invisible in a single line become a tree, and a missing field is obvious in a way it never was before. Third, check the counters: the character and key totals tell you whether the response is the object you expected or an error envelope you did not. Fourth, select the part you need and copy it into your code, your test fixture, or a bug report.

The same loop works for JSON Lines, the format where each log entry is its own JSON document on its own line. Formatting the whole file fails, because the file as a whole is not valid JSON. Validate one line at a time instead, then format the entry that broke.

Where a formatter stops

A formatter checks syntax, and syntax is a small part of correctness. A document can parse cleanly and still be wrong for your application, so paste it here and you get "valid" while your integration fails for a reason the parser cannot see. Validation against a JSON Schema, required fields, allowed value ranges, and the shape of nested objects are all separate checks, and they need separate tools.

Very large documents have their own limits. A formatter parses the whole text into memory before it can print anything, so a hundred-megabyte payload needs a browser tab that can hold it, and the result can feel slow on a modest laptop. For files that size, a command-line tool reading from a file is the better fit.

JSON.parse also accepts fewer things than people expect and more than the spec implies in one spot: duplicate keys are allowed by the grammar, and the last one wins in most JavaScript engines while others keep the first. If two services disagree about a payload like that, the discrepancy is in the data, not in the formatter.

Keeping a pasted payload private

Tokens, session cookies, customer records and internal hostnames all travel inside JSON payloads, so it matters where the text goes when you paste it. A client-side formatter never sends your document anywhere: the parsing happens in the tab, and the browser's network panel stays empty while you format.

If you want to confirm that for yourself, open the developer tools, switch to the network tab, paste a document and press Format. No request carries your text, and the page keeps working when the network is offline. That property is the reason a browser formatter is the right place for a payload you would not paste into a chat window, a random website, or an issue tracker.

shabbychef

San Francisco, CA · SO reputation 1999 · Badges: 3🥇16🥈29🥉 · SO member since 2009