Skip to content

JSON Formatter

Format, minify and validate, with errors located to the exact line and column.

Written and maintained by Mohit PatelLast checked August 4, 2026How we build these
Output
{
  "name": "The Calc Library",
  "tools": 12,
  "tags": [
    "free",
    "no sign-up"
  ],
  "nested": {
    "works": true,
    "depth": null
  }
}

Valid JSON: object, 6 keys, 2 levels deep.

Errors are located by a scanner rather than by reading the browser’s own message, which is worth explaining. V8 words a JSON failure two different ways depending on which check tripped, and one of them carries no position at all, only a truncated excerpt. Other engines differ again. Finding the problem directly gives an exact line and column every time, in every browser, with wording that says what was expected rather than what was found.

Nothing is uploaded. The document stays in this tab, which matters more for JSON than for most things, since it is usually somebody’s API response.

How the JSON Formatter works

Paste JSON and get it formatted, minified or validated. When it will not parse, you get the line, the column, the offending line quoted with a marker under the problem, and a message that says what was expected rather than repeating what was found. It also warns about integers too large to survive a round trip, which is the bug that quietly corrupts 64-bit IDs.

Also known as: json validator · json pretty print · json beautifier online · json minifier · format json online

The error message is most of the tool

Formatting JSON is not hard. Parse it, hand the result back to JSON.stringify with an indent, done in two lines. Everything that makes one formatter better than another happens when the JSON does not parse, which is most of the time you reach for one.

The browser's own message is not enough to build on, and the reason is specific. V8 produces two entirely different shapes depending on which internal check failed. Some failures give you 'Expected a comma or a closing brace in JSON at position 13 (line 3 column 3)', which is genuinely useful. Others give you 'Unexpected token, ..."b": ,"} is not valid JSON', which carries no position at all, only a truncated excerpt with ellipses in it. SpiderMonkey and JavaScriptCore word both cases differently again. A tool that scrapes those strings works on some errors, in some browsers, until the next release changes the wording.

So the position is found here by a scanner that walks the text itself. It costs about eighty lines and it pays for them: an exact offset for every failure, the same behaviour in every browser, and wording that describes what was expected rather than repeating what was found. JSON.parse still decides whether the document is valid, so the verdict always matches a real parser; the scanner only explains where it went wrong.

The number bug nobody warns you about

Every number in JSON becomes a JavaScript double when it is parsed, and a double holds integers exactly only up to 2 to the power 53, which is 9,007,199,254,740,991. Above that, digits start disappearing. Parse 9007199254740993 and you get 9007199254740992. Re-serialise it and that is what gets written back, silently, with no error anywhere.

This is not a theoretical problem. Twitter's snowflake IDs, Discord's, and any 64-bit database primary key all live comfortably in the range where it happens. A pipeline that reads JSON, changes one unrelated field and writes it back will corrupt every one of those IDs, and the corruption is invisible because the number still looks like a number.

The formatter here scans for integers of sixteen digits or more and checks whether they survive a round trip through a double. Anything that does not is listed with what it becomes. No other formatter I am aware of does this, which is a reason to do it rather than a reason not to. The fix, when you find one, is to send those values as strings, which is what most serious APIs do.

What JSON does not allow, and why you keep writing it

The specification is unusually small, and most of the errors people hit come from the gap between it and the JavaScript object literals that look almost identical.

Trailing commas are legal in JavaScript, in JSON5, in most config formats and in every linter's autofix. They have never been legal in JSON. Property names must be in double quotes, where JavaScript allows bare identifiers. Strings must use double quotes, where JavaScript accepts single. Comments do not exist, which is the single most requested change to the format and the one its author has been clearest about refusing. Numbers cannot have a leading zero, a leading plus, or a trailing decimal point, and cannot be NaN or Infinity.

Sorting keys is offered because it makes two documents comparable, and it is safe: the specification says object key order carries no meaning, so reordering changes nothing about the data. Array order is left alone, because there it is the data.

Frequently asked questions

Is my JSON uploaded anywhere?

No. It stays in the tab. That matters more for JSON than for most things, because it is usually somebody's API response and may well contain a token or a customer record.

Why are the error messages better than the browser's?

Because they do not come from the browser. V8 words a JSON failure two different ways depending on which check tripped, and one of them carries no position at all, only a truncated excerpt; other engines differ again. This finds the problem with its own scanner, so you get an exact line and column every time, in every browser.

What is the warning about large numbers?

JavaScript holds every JSON number as a double, so integers above about nine quadrillion lose their last digits. Parse 9007199254740993 and you get 9007199254740992 back, silently. It bites 64-bit database keys and snowflake IDs, and the fix is to send them as strings. No other formatter warns about it, so this one does.

Does sorting keys change my data?

It reorders object keys, which JSON treats as unordered, so the data is the same. Array order is left alone, because that is data rather than presentation.

Why does it reject trailing commas?

Because JSON does. A trailing comma is legal in JavaScript and in JSON5 and in several config formats, which is exactly why people write them by accident. Strict JSON has never allowed one, and the error message here says so rather than leaving you to spot it.

Related calculators