Introduction: Raw JSON Is Hard to Read, and Broken JSON Is Hard to Debug
JSON (JavaScript Object Notation) is the most common way applications exchange data, but the JSON you actually encounter in the wild is rarely pleasant to look at. An API returns everything on a single 4,000-character line. A configuration file has been hand-edited until an invisible mistake breaks the whole parser. A log entry contains a nested object five levels deep with no line breaks at all. In every one of these situations you need two things quickly: a clean, indented view you can actually read, and a definitive answer to the question "is this valid JSON, and if not, where is it broken?"
This guide is a practical, beginner-friendly walkthrough of formatting (also called pretty-printing or beautifying), minifying, and validating JSON directly in your browser. We will cover how to choose an indentation style, what validation actually checks, the handful of mistakes that cause the overwhelming majority of JSON errors, and exactly how to fix each one. You can follow along with our JSON formatter, which does all of this locally in your browser and never uploads your data anywhere.
Formatting vs. Minifying: Two Sides of the Same Coin
Formatting and minifying are opposite transformations of the same underlying data. Neither changes the meaning of the JSON — only its whitespace.
Formatting (pretty-printing) takes compact JSON and adds line breaks and indentation so the structure becomes visible. Every object property goes on its own line, nested objects and arrays are indented one level deeper than their parent, and matching brackets line up vertically. This is what you want when you are reading, reviewing, or debugging.
A minified object like this:
{"user":{"id":42,"name":"Ada","roles":["admin","editor"]}}
becomes, after formatting:
{
"user": {
"id": 42,
"name": "Ada",
"roles": [
"admin",
"editor"
]
}
}
Minifying does the reverse: it strips every non-essential space, tab, and newline, collapsing the whole document to a single line. This is what you want before shipping JSON over a network or embedding it in a file, because the smaller payload transfers faster and costs less bandwidth. The two operations are lossless and reversible — you can format minified JSON to read it, then minify it again to ship it, and the data is byte-for-byte identical in meaning.
Choosing an Indentation Style: 2 Spaces, 4 Spaces, or Tabs
When you format JSON, you choose how deep each nesting level is indented. There is no single correct answer, but there are sensible defaults and trade-offs worth understanding.
- 2 spaces is the most popular default in the JavaScript and web ecosystem. It keeps deeply nested structures from marching too far to the right, so more of each line stays visible without horizontal scrolling. Tools like Prettier and the npm ecosystem default to 2 spaces, which is why most JSON you see online uses it.
- 4 spaces produces more visual separation between nesting levels, which some people find easier to scan, especially in shallow documents. It is common in Python-influenced codebases. The downside is that deeply nested JSON quickly runs out of horizontal room.
- Tabs use a single tab character per level instead of spaces. The advantage is that each reader can configure how wide a tab appears in their own editor, so one person can view it as 2 columns and another as 8. The disadvantage is that tabs render inconsistently across web pages, diff viewers, and terminals, and mixing tabs with spaces produces messy, misaligned output.
The practical rule: pick one style per project and stick with it. If you are formatting JSON that will be committed to a repository, match whatever the rest of that project already uses so your change does not create a noisy diff where every line appears modified. If it is throwaway JSON you are only inspecting, 2 spaces is a safe, compact default. A good online formatter lets you switch between 2 spaces, 4 spaces, and tabs and re-render instantly, so you can try both and see which reads better for your particular data.
What Validation Actually Catches
Validation answers a strict yes-or-no question: does this text conform to the JSON grammar defined in RFC 8259? A validator parses the document character by character and stops at the first thing that violates the grammar, reporting the line and column where it gave up. It is important to understand what this does and does not check.
Validation does confirm that: strings are properly double-quoted and their escape sequences are legal; braces and brackets are balanced and correctly nested; commas separate elements but do not trail after the last one; keys are strings; and numbers, true, false, and null are written in their canonical form. If the parser reaches the end of the input with a complete, well-formed value, the document is valid JSON.
Validation does not check that your data means the right thing. A syntactically perfect JSON document can still have the wrong field names, missing required properties, a string where you expected a number, or an email address that is not really an email. That deeper, meaning-level checking is the job of a schema, which is a separate step. If you need to enforce structure and types, our JSON formatter pairs naturally with schema validation to catch both kinds of problems. For a broader treatment of designing well-structured payloads, see our guide to JSON best practices for API development.
The Most Common JSON Errors and How to Fix Each One
Nearly every JSON parse failure comes from one of a small set of mistakes. Learning to recognize them turns a cryptic "Unexpected token" message into a five-second fix.
1. Trailing Commas
This is the single most frequent JSON error. In JavaScript source code you are allowed to leave a comma after the last item in an array or object, but JSON forbids it. RFC 8259 requires that commas only ever separate two elements — there must be nothing but whitespace between the final element and its closing bracket.
Broken: {"a": 1, "b": 2,} — the comma after 2 is illegal.
Fixed: {"a": 1, "b": 2}
The fix is always to delete the comma that sits immediately before a closing } or ]. A validator points you straight at it, usually reporting the error at the closing bracket that follows the stray comma.
2. Single Quotes Instead of Double Quotes
JSON strings — both keys and string values — must be wrapped in double quotes. Single quotes are valid in JavaScript and Python but are not JSON. This trips up people who copy an object literal out of their code and expect it to be valid JSON.
Broken: {'name': 'Ada'}
Fixed: {"name": "Ada"}
The fix is to replace every single quote around a key or string with a double quote. Be careful with apostrophes inside a value: a name like O'Brien is perfectly fine inside double quotes ("O'Brien") and does not need to be touched.
3. Unquoted Keys
In JavaScript you can write an object as {name: "Ada"} with a bare, unquoted key. JSON does not allow this; every key must be a double-quoted string.
Broken: {name: "Ada", age: 30}
Fixed: {"name": "Ada", "age": 30}
The fix is to wrap each key in double quotes. This and the single-quote problem often appear together when someone pastes a JavaScript object literal and assumes it is JSON — the two languages look similar but JSON is a strict, quoted subset.
4. Missing or Mismatched Brackets
Every opening { needs a closing }, and every opening [ needs a closing ], correctly nested. A missing bracket, an extra one, or crossing them (closing an array with a brace) breaks the document. These errors are common after manually editing a large file, because it is easy to delete one bracket of a pair by accident.
Broken: {"items": [1, 2, 3} — the array is closed with a brace.
Fixed: {"items": [1, 2, 3]}
The most reliable way to find an unbalanced bracket is to format the document. Once it is indented, mismatched brackets become visually obvious because the indentation levels stop lining up. A validator will usually report the error at the point where it expected a closing bracket but found something else, which points you to the neighborhood of the mistake.
5. BOM and Encoding Issues
Sometimes JSON looks completely correct but still fails to parse, and the culprit is invisible. A common cause is a byte order mark (BOM) — a special, unprintable sequence that some editors (notably older versions of Windows Notepad) insert at the very start of a file when saving as UTF-8. RFC 8259 states that JSON text must be encoded in UTF-8 and that implementations are not required to accept a leading BOM, so a BOM at the start of the file can cause a parse error on the very first character even though the visible text is flawless.
Other invisible troublemakers include non-breaking spaces pasted from a web page or word processor (which look like normal spaces but are a different character), smart or curly quotes that a word processor substituted for straight quotes, and stray control characters. The fix is to re-save the file as plain UTF-8 without a BOM, retype any suspicious quotes as straight double quotes, and replace exotic spaces with ordinary ones. If a document validates when you retype it by hand but fails when you paste it, an invisible character is almost always the reason.
6. Comments, Special Numbers, and Other Non-JSON Extras
A few more habits from other languages produce invalid JSON. Comments are not allowed — neither // line comments nor /* block comments */ — so remove them or move them into a real string field. The special floating-point values NaN, Infinity, and -Infinity are not valid JSON numbers; you must represent them as strings or null and interpret them in your application. And while JSON technically permits duplicate keys in an object, most parsers silently keep only the last one, so duplicates are best treated as a bug to fix rather than a feature to rely on.
Minifying JSON: When and Why
Once your JSON is valid, minifying it is the natural final step before you send or store it. Minification removes the indentation and line breaks that made it readable, shrinking the payload. For a large configuration object or an API response, this can meaningfully reduce transfer size. The workflow is simple: format while you work so you can read and verify the structure, then minify the final version for delivery. Because the transformation only touches whitespace, a value that was valid when formatted is still valid — and identical in meaning — when minified.
One practical note: minification and server-side compression (gzip or brotli) overlap. If your server already compresses responses, the extra savings from minification are smaller, but minifying still helps clients that do not request compression and slightly reduces in-memory parsing cost. Formatting for humans and minifying for machines is a good default habit either way.
Why a Client-Side Tool Keeps Your Data Private
JSON often contains sensitive information: API keys, authentication tokens, customer records, internal identifiers, or personal data in a response payload. Pasting that into a website that sends it to a server for processing means handing your data to a third party you may know nothing about. That is a real privacy and security risk, especially with production credentials or regulated data.
A client-side tool avoids the problem entirely. Our JSON formatter and validator runs completely in your browser using JavaScript. When you paste JSON and click format, the parsing, indentation, and validation all happen on your own machine. Nothing is uploaded, nothing is logged on a server, and the tool works even if you disconnect from the internet after the page loads. You get the convenience of an online tool with the privacy of an offline one — which is exactly what you want when the data you are inspecting is not yours to leak.
A Simple Workflow to Format and Validate JSON Online
- Paste your JSON into the input area of the formatter. It can be a single minified line, a partially formatted blob, or something you just hand-edited.
- Format it to pretty-print with your chosen indentation. If the structure renders cleanly with brackets that line up, you can already see the shape of your data.
- Read the validation result. If the JSON is valid, you get a confirmation. If not, the tool reports the line and column of the first error — jump there and apply the matching fix from the list above.
- Fix and re-check until it validates. Most documents have only one or two of the common errors, and each fix is mechanical once you can see where it is.
- Minify the final version if you are about to send or store it, and copy the compact output.
With this loop, formatting and validating JSON becomes a routine, low-stress task rather than a hunt for an invisible mistake. Learn the six common errors, keep a consistent indentation style, and use a browser-based tool that keeps your data on your own machine. When you are ready to go deeper on how JSON objects are actually defined, our explainer on RFC 8259 object syntax covers the grammar in detail, and our JSON best practices guide shows how to design payloads that are easy to format, validate, and consume.