JSON formatter and validator

Where messy JSON comes from

Most JSON you meet in practice was written by a program for another program, so it arrives as one long line: an API response copied from the browser's network tab, a webhook payload in a log file, a config value stored in a database column. Reading a 4,000-character single line to find one nested field is slow and error-prone. Pretty-printing puts every key on its own line and indents each level, so the structure becomes visible at a glance.

The reverse is just as common. Before you paste JSON into an environment variable, a query string, a test fixture or a chat message, you often want it as compact as possible. Minifying removes every space and line break that sits outside string values; a typical indented config file shrinks by 20 to 40 percent, depending on how deep it nests.

What the formatter does to your data

The input is parsed with the browser's native JSON parser and written back out with the indentation you chose: 2 spaces, 4 spaces or a tab. Minify uses the same path with no indentation at all. Because the document is rebuilt from the parsed value rather than edited as text, a few details can change, and it is worth knowing which:

• Number notation is normalised. 1.0 becomes 1, 1e3 becomes 1000, and -0 becomes 0. The value is the same, the spelling is not.
• Very large integers lose precision. JavaScript stores numbers as 64-bit floats, which are exact only up to 9,007,199,254,740,991. A 19-digit ID such as 12345678901234567890 comes back as 12345678901234567000. If your data has Snowflake-style IDs, database bigints or payment amounts in minor units at that scale, compare the output before using it.
• Unicode escapes are decoded. "caf\u00e9" is written back as "café". Both are valid JSON and mean the same string.
• Duplicate keys collapse. If an object contains the same key twice, only the last value survives. The JSON standard leaves duplicates undefined, and most parsers behave this way.
• Integer-like keys move to the front. Keys that look like non-negative whole numbers, such as "2" or "10", are placed first in ascending order, ahead of all other keys. This is a rule of JavaScript objects, not of JSON. Ordinary text keys keep their original order.

None of this matters for typical API payloads, but it does matter if you are about to commit a formatted file and want a minimal diff.

Reading the error position

When parsing fails, the tool runs its own small scanner to find the first character that cannot continue a valid document, and reports that as a line and column.

The reported spot is where the parser gave up, which is not always where the mistake was made:

• A trailing comma in [1, 2, ] is reported at the closing bracket, because a value was expected there.
• A missing comma between two properties is reported at the start of the second key.
• A missing closing brace or bracket is reported at the very end of the input, sometimes hundreds of lines below the real problem. Look for the last object or array that was opened.
• A string missing its closing quote is reported at the end of its line, because a raw line break is not allowed inside a JSON string. The same position appears for multi-line text pasted into a value; line breaks there must be written as \n.

If the input is not really JSON but a JavaScript object literal, YAML or a Python dict printed with single quotes, the error will appear on the first line or two. Those formats look similar but are not interchangeable.

Choosing an indent

• 2 spaces is the default in most JavaScript tooling, package.json files and many style guides. It keeps deeply nested data from drifting off the right edge of the screen.
• 4 spaces matches what Python's json.dumps(indent=4) produces and reads more easily for shallow documents.
• Tab lets each reader choose the visual width in their editor and produces slightly smaller files than 4 spaces.

For files that live in a repository, match whatever the project already uses; mixing styles makes every diff noisy.

Next steps with formatted data

Once the structure is readable, other tasks get easier. To spread an array of records into a spreadsheet, convert it with JSON to CSV. To see exactly what changed between two versions of a payload, format both with the same indent and compare them in text diff; identical formatting means the diff shows only real changes. Everything happens in the page, so tokens and personal data in a payload stay on your device.