JSON formatter and validator — find the broken line

No. The parser runs inside this page, in your browser. Nothing you paste is sent over the network, which is the point — API responses and config files routinely carry keys, tokens and customer records, and pasting those into a server-side formatter hands them to a stranger.

Every browser writes its own JSON error message, and they disagree. Chrome gives a character position, Firefox gives a line and column, and Safari gives neither. This tool scans the text itself to locate the first error, so you get the same answer everywhere.

A trailing comma before a closing bracket, property names without double quotes, single quotes instead of double, and a line break typed inside a string. All four are named explicitly here rather than reported as an unexpected token.

It changes the order keys are written in, which JSON treats as insignificant, so any parser reads the result as the same object. Array order is never touched — in an array, order is meaning.

Formatting handles multi-megabyte documents fine. The tree view stops at 15,000 nodes, because drawing an element per node past that point locks up the tab. The formatted text keeps working above that limit.

No, deliberately. Those are extensions that real JSON parsers reject, so accepting them here would tell you a file is fine when the service you are sending it to will refuse it.

Structure without scrolling. A 4,000-line API response indented to two spaces is still 4,000 lines; collapsed to a tree it is a handful of top-level keys you can open one at a time. It is the faster way to answer "does this response contain a field called customerId, and where" — and because every node stays in the document, browser find still works across the parts you have opened.

Because it came out of a Windows editor, a spreadsheet export, or a copy-paste from a web page. A byte order mark is three invisible bytes at the very start of a file that a strict parser reads as an unexpected character before the opening brace — which is why the error points at position 0 on a document that looks perfect. Non-breaking spaces pasted from a browser cause the same class of confusion, and both are located here by position rather than described vaguely.

The formatted output preserves the text you pasted, so a number written as 1.50 stays 1.50 and an ID longer than JavaScript can hold as a number is not rounded on its way through. This matters more often than it sounds: a 19-digit identifier passed through a formatter that parses to a number and prints it back comes out with the last two digits wrong, silently, and nothing downstream will tell you.

No, and the gap is where most hand-written JSON breaks. JavaScript allows unquoted keys, single quotes, trailing commas, comments and undefined; JSON allows none of them. Something that pastes happily into a browser console can still be rejected by every API you send it to, which is why this tool validates strictly rather than accepting what a JavaScript parser would.

Anything, in the sense that matters: the parsing happens in this tab and nothing is transmitted. That is worth stating plainly because API responses routinely carry access tokens, customer names, email addresses and payment references, and the habit of pasting them into whichever formatter ranks first is how those end up in a stranger’s server log. Nothing is written to browser storage here either — closing the tab is the end of it.

Indentation can be a third of a document. That matters when JSON is going into an environment variable, a query string, or a request body sent thousands of times a day — and none of it changes the parsed value.