dummy4u

JSON Formatter and Validator

Formats as you type. When something is wrong, it tells you the line, the column and what it expected instead.

Options

Where the error actually is

Most online validators pass the browser's own error message straight through, which is a problem because the engines disagree. Chrome tells you "Unexpected token } in JSON at position 42". Firefox says "line 3 column 8". Safari says "Unexpected token '}'" and gives you no position at all. Paste the same broken file into three browsers and you get three different levels of help.

This page locates the fault itself, so the answer is identical everywhere: line, column, an excerpt of the offending line, and a caret under the exact character. The native parser still decides whether your JSON is valid — no reimplemented grammar to quietly disagree with your runtime — but the position and the explanation come from here.

The five things that are usually wrong

  • A trailing comma. {"a": 1,} is legal in JavaScript and illegal in JSON. Easily the most common cause.
  • Single quotes. {'a': 1} is a JavaScript object literal, not JSON. Keys and strings both need double quotes.
  • Unquoted keys. {a: 1} — same cause, same fix.
  • JavaScript values that JSON has no concept of. undefined, NaN, Infinity and functions are all out. null is the only empty value.
  • Malformed numbers. No leading zeros (01), no leading plus (+1), no bare decimal (.5), no hex (0x1F).

If your file legitimately contains comments or trailing commas, it is JSONC or JSON5 rather than JSON — used by tsconfig.json and VS Code settings among others. Strict parsers will reject it, correctly.

Sorting keys is underrated

Tick Sort keys alphabetically and object keys are ordered recursively. This is the quickest way to diff two API responses that contain the same data in a different order: sort both, format both, and the diff collapses to the fields that genuinely changed instead of the whole file.

Note that JSON object keys have no defined order, so no consumer should depend on it. Sorting is a tool for reading and comparing, not something to preserve.

One limitation worth knowing

This tool parses to JavaScript values and re-serialises them, which means very large integers lose precision. JavaScript numbers are IEEE-754 doubles, so anything beyond 9,007,199,254,740,991 is rounded: a 64-bit Twitter-style ID such as 9007199254740993 comes back as 9007199254740992. That is a property of the language, not a bug here, but it is why APIs that use 64-bit IDs send them as strings. If your payload contains large integer IDs, treat the formatted output as a view rather than a source of truth.

Everything else round-trips exactly, including Unicode escapes, which are decoded to their characters on output.

Common questions

Is my JSON uploaded?
No. Parsing and formatting happen in your browser and the page makes no network requests. That is the main reason to use a tool like this one rather than pasting a production payload into an unknown site. See the privacy policy.
How large a file can it handle?
Formatting is instant up to a few megabytes. Above 256 KB the live-as-you-type behaviour switches off and it waits for you to press Format, so a large paste does not cause the page to stutter on every keystroke.
Does it validate against a schema?
No — this checks syntax, not structure. For a contract check you want JSON Schema validation, which is a different and much larger job.
Why does the output reorder my Unicode escapes?
é and é are the same character, and the serialiser emits the literal form. If you need the escaped form preserved, the input was probably not meant to be re-serialised at all.