JSON
JSON formatter, validator and explorer
Paste your JSON and see it formatted as you type. If something is wrong we tell you the line, the column and what was expected there. With a tree view, a search box and YAML conversion.
Your JSON never leaves your machine: it is parsed, formatted and converted right here.
Why it matters that your JSON is not uploaded
What gets pasted into a formatter is rarely a textbook example: it is a production API response full of real customer data, a config dump with credentials in it, or the body of a webhook you are debugging at eleven at night. Sending that to some website's server so it can pretty-print it means handing over data that inside your company sits behind three layers of permissions. Here there is nowhere to send it: the text is parsed in your tab and stays there.
How it works, in 3 steps
-
Paste the JSON
Or drop the file on top. YAML and JSON Lines work too: switch it in the selector on the left, and if you pick the wrong format the tool spots it and offers to fix it.
-
Look at it however suits you
Formatted with the indentation you actually use, as a collapsible tree for navigating a big one, or converted to YAML or JSON Lines.
-
Copy it or download it
If there is a syntax error we point at it first — line, column, and an explanation of what is missing there.
What people use it for
- Reading an API responsePasting the body a request returned and seeing at a glance what is in it, instead of staring at one 4,000-character line.
- Finding the syntax errorWhen the deploy fails with “unexpected token” and you have to find the one spare comma in a 900-line file.
- Exploring a huge JSONCollapsing what you don't care about and searching for one key among thousands, without drowning in two thousand open lines.
- Going from JSON to YAMLConverting a config for a Helm chart, a compose file or a pipeline — and back again when it arrives as YAML.
- Minifying before sendingStripping every bit of whitespace to fit it into an environment variable, a header, or a field with a tight size limit.
- Checking an exportSeeing how many records it holds, how deep it nests and whether any key is duplicated, before importing it anywhere.
A JSON validator that says where the fault is, not just that there is one
Most validators tell you exactly what the console already told you: Unexpected token } in JSON at position 1847. That position is a character offset, so to use it you have to count. And “unexpected token” describes the symptom, not the cause: the } is bothering nobody — what is wrong is the comma on the line before.
So this tool does not use JSON.parse under the hood. It carries its own parser, which walks the text always knowing what it is expecting to find, and when something does not fit it reports the line, the column and what should have been there. Spare comma? It says so. Single quotes? It says so. Pasted Python's True? It reminds you JSON wants it lowercase. And there is a button to jump straight to the exact spot in the text.
That own parser brings two more advantages that show up with real data. First: it preserves the actual key order. Run it through a JavaScript object and keys that look like integers — "1", "2", "10" — quietly reorder themselves ahead of the rest, and the JSON handed back to you is no longer the one you pasted. Second: it preserves each number's original text. A twenty-digit identifier loses precision the moment it passes through a JavaScript number, and 12345678901234567890 comes back as 12345678901234567000. Here, beautifying and minifying do not touch a single digit.
The tree view is for the JSON that won't fit in your head
Formatting forty lines of JSON is something your editor already does. The problem starts at a thousand lines, four thousand, forty thousand: however neatly indented, finding one thing means scrolling forever and losing track of where you are.
In the tree view every branch collapses, and each branch tells you its type and how many items it holds before you open it. That way you see the shape of the document — “this is a list of 1,200 orders, each with 14 fields” — without opening anything. The search box filters by key or value and leaves only the branches leading to a match on screen, with the hit count.
It is built to cope: branches do not exist in the page until you expand them, so opening a big file is instant even at hundreds of thousands of nodes. And on levels with enormous numbers of children the first two hundred are shown with a button to fetch more, rather than freezing the tab.
JSON to YAML, and YAML to JSON
Anyone formatting JSON needs YAML about five minutes later, because Kubernetes configs, CI pipelines and compose files live in YAML while APIs speak JSON. Conversion runs both ways: the YAML tab converts whatever you have, and switching the input format to YAML lets you paste YAML and see the equivalent JSON.
The delicate part of emitting YAML is quoting, and that is where many converters fall over. In YAML, unquoted yes, no, on and off turn into booleans; 007 turns into the number 7; 2026-01-01 turns into a date; and null stops being the string “null”. All of that gets quoted here so the value stays exactly what it was, and the output is checked by reading it back with a real YAML parser.
The limits, stated before they bite
Dropping a file caps at 8 MB. Parsing handles a good deal more, but above roughly 6,000 output lines highlighting and line numbers switch off and plain text is shown: painting one element per line across tens of thousands of lines chokes any browser, and saying so beats hanging. The tree view is immune to that because it only builds what you open. Nesting is capped at 200 levels, which in practice is only reached by mistake.
If what you actually have is a CSV or a spreadsheet and what you want is SQL statements, the CSV to SQL converter does that — also without uploading anything.
And if what you want is to see what changed between two versions of a JSON file, format both with the same indentation and run them through the text comparer: with the indentation matched, the differences that show up are the real ones rather than two different ways of writing the same thing.
And if what you need is to pull a handful of values out of a huge dump without writing code, a regular expression is often the shorter route: the regex tester lets you refine one against the real text and explains what each piece does.
Frequently asked questions
Why is a trailing comma an error when my editor accepts it?
Because JavaScript allows trailing commas and JSON never has. The last item in an object or array carries no comma after it.
Your editor lets you type one because it is thinking about a .js file, and Python or Node forgive it in code. But the moment that text travels as actual JSON, every parser rejects it. By far the most common error.
Can I use single quotes in JSON?
No. JSON only understands double quotes, for keys and string values alike.
Single quotes are valid in JavaScript and Python, which is why this shows up right after copying a Python dict or a JS object literal and calling it JSON. Backticks are the same story.
Why do keys have to be quoted?
Because in JSON a key is always a string, and strings are double-quoted. JavaScript lets you write them unquoted when they are valid identifiers, and that shortcut sneaks in when copying code.
If the key has a hyphen or a space the difference is obvious; if it is an ordinary word the error is surprising, but the rule is the same.
What about comments?
JSON allows no comments, neither // nor /* */. Douglas Crockford removed them deliberately so nobody would use them as parsing directives.
If yours came from a tsconfig.json or a VS Code settings.json, that is JSONC — JSON with comments — a dialect those tools understand and almost nothing else does. They have to go before treating it as JSON.
Is my JSON uploaded to a server?
No. Parsing, formatting, the tree and the conversion all happen in your browser. No accounts, no database. Load the page, disconnect from the internet and check: it keeps working.
What is the difference between JSON and JSON Lines?
A JSON file is a single document. In JSON Lines every line is a complete, independent document, with no commas or brackets wrapping them.
It is used for logs and large exports: readable line by line without loading the whole file into memory, and appending a record is writing one line at the end. This tool reads and writes both.
Why does my number look different after formatting?
It should not here. JavaScript numbers are double precision, so an identifier longer than sixteen digits gets rounded: 12345678901234567890 ends up as 12345678901234567000.
This tool keeps each number's original text, so beautifying or minifying changes nothing. If another tool mangled a long identifier for you, that is why.
What happens with a duplicate key?
Technically it is valid: the spec does not forbid it, it just leaves the behaviour undefined. In practice nearly every parser keeps the last one and silently drops the earlier, which is the worst way to lose a value.
So rather than let it pass, the tool flags the key and the line.
Is there a size limit?
For a dropped file, 8 MB. Above roughly 6,000 output lines the highlighting and line numbers switch off and plain text is shown, because painting one element per line across tens of thousands of lines chokes the browser. The tree does not have that problem: it only builds the branches you open.