JSON Formatter / Minifier / Validator

JSON Validation: The Seven Most Common Syntax Errors and Their Real Messages

What formatting and minification actually do

The JSON specification defines whitespace as semantically meaningless. Newlines before or after braces, spaces after colons, and any amount of indentation are all ignored by a parser. That single fact drives the two operations this tool performs:

• Format (beautify): inserts newlines and indentation per nesting level so a human can read the structure. It exists for people.
• Minify: deletes every whitespace character that the grammar allows to be omitted, producing the smallest possible text. It exists for machines to transmit.

Neither operation changes the data itself — with one exception: the written form of numbers. A parser treats 1.0 and 1 as the same value, so a formatter may rewrite the former as 1. The same happens to 1e3, which becomes 1000, and to -0, which becomes 0. Numerically these pairs are equal and -0 is also equal to 0 in most languages, but if a downstream system compares the payloads as exact strings, the difference will surface as a mismatch that looks like data corruption.

How much does minification save? Usually between 10% and 30% of the byte size. But there is an important caveat: if your HTTP responses are already compressed with gzip or brotli, the extra saving from minifying JSON is small, because the compression algorithm itself removes the redundancy of repeated whitespace and repeated key names. Minifying JSON earns its keep in different places: data inlined into HTML or JavaScript, message bodies written to a queue or a store, and anywhere there is a hard size ceiling such as a URL, a Cookie, or LocalStorage.

One more rule worth stating up front: key order carries no meaning. The specification is explicit that an object is an unordered collection of key-value pairs. So if a formatter or minifier changes the order of keys, that is not a data change and should not be treated as one.

The seven most common syntax errors

Error number 4 deserves a longer note. Comments are common in configuration files, but standard JSON forbids them. The formats that allow comments have their own names — JSON5 (which permits comments, single quotes, trailing commas, unquoted keys, and hexadecimal numbers) and JSONC (JSON with Comments, the dialect used by VS Code settings.json and TypeScript tsconfig.json). Both are supersets of JSON, which means a standard JSON parser cannot read them. If your configuration needs comments, first confirm which dialect the reader supports.

Two traps that do not raise an error

Duplicate keys. This JSON is legal and parses without complaint: {"a":1,"a":2}. The specification does not define what should happen with duplicate keys, and the behavior of JSON.parse is to keep the last value and silently discard the earlier one. That means a hand-written or concatenated mistake producing a duplicate key will change your data in silence — no error, no warning. When you are hunting down a value that is mysteriously wrong, this is a specific thing worth checking.

Large-integer precision loss. A JSON number in JavaScript is an IEEE 754 double-precision float, and the largest integer it can represent exactly is 2⁵³-1, which is 9007199254740991 (sixteen digits). Beyond that, precision is lost:

{"id": 9007199254740993} parsed and then serialized again becomes 9007199254740992.

This is a limitation of this tool's JavaScript number parsing, not an inherent limit of the JSON text format. It can affect large numeric identifiers and high-precision amounts. For identifiers, ask the producer to serialize them as strings. If you cannot change the producer, use a parser that explicitly preserves the precision you need. Avoid generic regular-expression rewrites of JSON: they can alter quoted text or miss valid numeric forms.

What to check beyond validation

Passing the syntax check does not mean the structure is correct. {"user":{"name":123}} is valid JSON, but if the contract says name is a string, it is wrong. Syntax-level validation (what this tool does) and structure-level validation (JSON Schema, Zod, pydantic, and similar) are two different jobs.

Also, never use eval() to parse JSON. Because JSON is a subset of JavaScript syntax, eval can "parse" it — but it will also execute any code that was smuggled in. JSON.parse accepts data only, never expressions, and that restriction is the entire reason it exists.

How to use this tool

1. Paste your JSON into the input box.
2. Click format to get an indented version, or click minify to get a single-line version.
3. If the syntax is wrong, the tool points to the exact location (line and column) and the reason. The fastest way to find a stray comma or quote at a boundary is to look at that position.

All parsing and formatting happen locally in your browser, so sensitive data returned by an API never leaves your device.