How to Format and Validate JSON Online for Free (Fix Errors With Exact Line and Column)

To format JSON online for free, paste your JSON into the JSON Formatter & Validator, choose Format with 2 or 4 spaces to pretty-print it, Minify to collapse it to one line, or Validate only to check it without changing it — if the JSON is invalid, the tool shows the parser message with the exact line and column and the offending line marked with a caret, and everything runs entirely in your browser, so nothing is uploaded.

JSON is the format APIs speak. A product feed, a webhook payload, a configuration export, a response copied out of a browser's network tab — most of them arrive as one dense, unbroken line that no human can review. Formatting does not change the data at all; it changes whether a person can read the data, spot the missing comma, and trust what they are about to paste into a live system. That is why a formatter earns its place in everyday work: the five minutes it saves on one payload are useful, but the production mistake it prevents is the real value. This guide covers how the tool works, what its error messages actually mean, the strict rules JSON follows, and the important limit that a validator checks syntax only — never whether the content itself is correct for your purpose.

What the Tool Does, Button by Button

Paste your JSON into the input box and the character and line counts update live as you type or edit, which is handy when an API imposes a size limit or when you want to confirm that a paste arrived complete. Format reprints the data with consistent indentation — 2 spaces is the common choice for code and config files, 4 spaces suits people who find wider spacing easier to scan. Minify does the opposite, stripping every optional space and line break to produce the smallest valid single-line form. Validate only runs the check without reformatting, so you can confirm a file is sound while leaving its original layout untouched. When you are done, Copy takes the result to your clipboard and Download saves it as a .json file.

Action	What happens	Reach for it when
Format (2 spaces)	Data is parsed, then reprinted with 2-space indentation	Reviewing, debugging or editing a payload by hand
Format (4 spaces)	Same reprint with wider 4-space indentation	Reading deeply nested data, or matching a house style that uses four spaces
Minify	All optional whitespace removed; output is one line	Sending data compactly, or fitting a strict size limit
Validate only	Syntax is checked; layout is left exactly as pasted	A quick soundness check before importing or uploading a file
Copy / Download .json	Result goes to the clipboard or saves as a file	Moving the cleaned version into your project or sending it on

Under the hood there is no mystery, and knowing the mechanism explains both the power and the limits. Formatting means the tool first parses your text into real data — which is the step that fails when the syntax is broken — and then reprints that data with JSON.stringify using your chosen indentation. Because the output is regenerated from the parsed data rather than tidied up character by character, stray spacing, inconsistent line breaks and jumbled indentation all disappear in one pass. It also means a formatter can never silently fix a syntax error for you: if the parse step fails, there is no data to reprint, and the error message is the whole result.

Reading the Error Message: Line, Column and Caret

When JSON is invalid, the tool shows the parser's own message together with the exact line and column where parsing failed, and displays the offending line with a caret pointing at the position. Treat those three pieces as a single clue. The line tells you where to look, the column narrows it to a spot on that line, and the caret removes the counting. One habit saves repeated frustration: remember that parsers often report the position where they noticed the problem, which can be one token after the actual mistake. If the caret sits on a closing brace or the start of the next key, look just before it — a missing comma at the end of the previous line is the usual culprit. Fix one error at a time and validate again, because a single early fault can produce a cascade of confusing later messages that vanish once the first is repaired.

The chart uses one stated sample so every figure can be checked by hand: the payload {"name":"Asad","city":"Karachi","tools":["JSON","Base64"],"active":true}. Minified, it is 72 characters on 1 line. Formatted with 2 spaces, the same data is 102 characters over 9 lines. Formatted with 4 spaces, it is 120 characters, still over 9 lines — the line count stays the same because the structure is identical; only the indentation width grows. The lesson generalises: formatting always costs characters and buys readability, minifying always does the reverse, and neither changes a single value in the data. Anyone quoting a size difference for a real payload should be able to show the payload, exactly as here.

A Worked Example, From Broken to Clean

The tool's own page offers the smallest useful illustration. The payload {"a":1,"b":[2,3]} is valid: an object with a number and an array of two numbers. Formatted with 2 spaces it becomes seven readable lines — opening brace, the "a" entry, the "b" entry opened, the two numbers each on their own line, then the closing brackets. Change one character and the picture flips: {"a":1,} — the same text with a trailing comma after the 1 — is invalid JSON, and the validator will refuse it and point at the position of the problem. That tiny pair of examples carries the most important practical rule in this guide: JSON is stricter than the JavaScript it resembles. Trailing commas that JavaScript tolerates are errors in JSON, every time.

The Strict Rules JSON Actually Follows

Most validation failures come from a short list of rules that differ from everyday JavaScript and from casual handwriting. Keys must be wrapped in double quotes — single quotes and bare words are not allowed. Strings must use double quotes too. Comments do not exist in JSON: neither line comments nor block comments, however helpful they would be in a config file. Trailing commas are forbidden after the last entry in an object or array. Numbers cannot carry leading plus signs or casual leading zeros, and the only literal values are true, false and null, written in lower case. When a validator rejects a file you received from another system, check these five points first — in practice one of them is almost always the cause, and the line and column in the error message will be standing right next to it.

Common habit	Valid in JSON?	Correct form
Trailing comma: {"a":1,}	No	{"a":1}
Single-quoted strings: {'a':1}	No	{"a":1} — double quotes only
Comments inside the data	No	Keep notes outside the JSON file
Unquoted keys: {a:1}	No	{"a":1}
Undefined or NaN as a value	No	Use null, or a real number or string

Syntax Is Not Meaning: The Limit to Understand

A green validation result means exactly one thing: the text follows the JSON grammar, so any standard parser can read it. It does not mean the data matches a schema, contains the fields your integration expects, uses the right types, or holds sensible values. A payload can be perfectly valid JSON and still name the price field "prce", send a quantity as the string "ten", or omit a customer identifier entirely — validation passes it, and the receiving system fails later, somewhere harder to debug. Serious workflows therefore treat the two checks as separate steps: validate syntax here, in seconds, before anything is sent; then check the content against the agreed structure — required fields, types and allowed values — with schema validation or a careful read of a formatted printout. Formatting genuinely helps the second step too, because a human reviewing an indented document spots a misspelled key far faster than the same person squinting at a single line. Just never let a passed syntax check be reported as proof that data is correct; it is proof that data is readable, which is the necessary first step and nothing more.

Privacy: Why "Runs in Your Browser" Matters Here

JSON payloads routinely contain material that should not travel: customer records from an export, order details, internal identifiers, configuration values, tokens that a developer pasted into a test payload and forgot. This formatter runs entirely in the browser — the parsing and reprinting happen with the JavaScript engine already on your device, and nothing is uploaded to a server to be formatted. That design removes a whole category of worry from a routine task: you can clean up a client payload, a support export or a webhook sample without first scrubbing it or wondering where copies might be retained. The sensible habits still apply — do not leave sensitive payloads sitting in shared screenshots, and close tabs on shared machines — but the tool itself adds no upload, no account and no stored history to the process.

Five JSON Mistakes That Waste the Most Time

• Adding a trailing comma out of JavaScript habit. The last entry in an object or array takes no comma; {"a":1,} fails, and it is the single most common hand-editing error.
• Quoting with single quotes, or not at all. JSON demands double quotes around every key and every string. Text copied from code samples often arrives with JavaScript quoting and must be corrected, not argued with.
• Writing comments into the file. JSON has no comment syntax. Notes belong in a companion document; a comment pasted into a payload makes the whole file invalid.
• Treating "valid" as "correct". Validation proves grammar, not content. A misspelled field name or a number sent as text passes validation and breaks the receiving system later.
• Editing the minified line by hand. One character wrong in a thousand-character line is nearly impossible to find. Format first, edit the readable version, then minify again if the destination wants it compact.

Related Tools and Guides

JSON rarely travels alone, and the neighbouring tools cover its usual companions. Encoded values inside a payload — tokens, keys and embedded blobs — are the territory of the Base64 Encoder/Decoder, while the tokens themselves open up in the JWT Decoder, which reads the header and payload of a JSON Web Token. The formatter itself lives at the JSON Formatter & Validator. For the same "open an unfamiliar data file safely in the browser" idea applied to databases, our guide to viewing SQLite database files online walks through browsing tables and running read-only queries with nothing uploaded.

Frequently Asked Questions

Is the JSON Formatter free, and is my JSON uploaded?

Yes, it is free, and no — nothing is uploaded. Formatting and validation run entirely in your browser on your own device, so you can paste client payloads and exports without sending them to a server.

What is the difference between Format, Minify and Validate only?

Format reprints your JSON with 2-space or 4-space indentation so a person can read it. Minify removes all optional whitespace into a single compact line. Validate only checks the syntax and leaves your layout exactly as pasted.

Why does the tool say my JSON is invalid when it works in my code?

JSON is stricter than JavaScript. Trailing commas, single-quoted strings, unquoted keys and comments are all tolerated in some code contexts but are errors in JSON. The error message gives the line and column, and the offending line is shown with a caret.

The caret points at a line that looks fine. What should I check?

Parsers often report where they noticed the problem, which can be just after the real fault. Check the end of the previous line for a missing comma, and check the highlighted area for a missing closing quote or bracket.

Does a valid result mean my data is correct?

No. Validation checks syntax only — that the grammar is right and any parser can read the file. It does not check schemas, required fields, types or sensible values, so content checks remain a separate step.

Can the formatter fix broken JSON automatically?

No, and it should not guess. Formatting works by parsing the text and reprinting the parsed data, so a syntax error stops the process and the message explains where. Fix the pointed error, then format.

Which indentation should I choose, 2 or 4 spaces?

Either is valid — the data is identical. Two spaces is the common convention in code and config files and keeps files compact; four spaces can be easier to scan in deeply nested payloads. Match the convention of the project the file belongs to.