JSON Formatter & Validator

A JSON formatter is the first tool anyone reaches for when an API response refuses to parse. JSON is simple enough that everyone thinks they can eyeball it, and large enough that nobody actually can. A JSON formatter is the difference between finding a missing comma in two seconds and finding it in ten minutes — and because formatting requires a complete parse, the same operation doubles as validation. If the document formats, it parses.

Why pretty print JSON instead of reading it raw? JSON from a server arrives as one long line of compact text — correct for the network, useless for a human. When you format JSON, every level of nesting moves one step to the right and the shape of the data becomes visible at a glance. Reviewing an API payload, checking a config file or attaching a sample to a bug report are all faster with formatted JSON, and pasting it into a JSON formatter is the quickest syntax sanity check there is.

What "valid JSON" actually requires

The specification is small and unforgiving:

• Strings must use double quotes. Single quotes are invalid.
• Object keys must be quoted strings. Unquoted keys are JavaScript, not JSON.
• No trailing commas. [1, 2, 3,] and {"a": 1,} both fail.
• No comments. // and /* */ are not part of JSON — JSONC and JSON5 add them, and many config parsers accept them, but a strict parser will not.
• Only six value types: object, array, string, number, true, false, null. Not undefined, not NaN, not Infinity, not dates.
• Numbers cannot have a leading plus, cannot be hexadecimal, and cannot have a leading zero before a digit sequence.

Most "why is my JSON broken" questions are answered by that list.

Reading the error output from the JSON validator

A native parse failure reports a character position, which is useful but not directly navigable. This JSON validator converts that offset into a line and column number and shows the surrounding text with a caret under the offending character. When the reported position is the end of the document, the real problem is almost always an unclosed bracket earlier — count your braces.

The failures a JSON syntax checker meets most often, in rough order of frequency:

• A trailing comma after the last element of an object or array.
• A string opened with a single quote, or smart quotes pasted from a document or chat app.
• An unquoted key, usually written by someone thinking in JavaScript object literal syntax.
• An unterminated string, where a missing closing quote swallows the rest of the document.
• A literal line break inside a string, which JSON does not allow and which must be written as an escaped sequence instead.

Each of these is a one-symbol fix once the validator has pointed at the exact position — which is precisely why a JSON validator with line and column reporting beats a parser that throws a bare "unexpected token".

Indentation choices in a JSON formatter

Two spaces is the prevailing convention in JavaScript and Node ecosystems and what JSON.stringify(value, null, 2) produces.

Four spaces is common in Python and Java shops and easier to read in deeply nested documents.

Tabs keep indentation width a viewer preference rather than a file property.

Whatever you choose, be consistent — mixed tabs and spaces are invisible in most editors and maddening in diffs.

Sorting keys in formatted JSON for diffing

Alphabetically sorted keys turn a structural comparison into a line comparison. Two versions of the same config diff cleanly line by line instead of showing a whole object as changed because a member moved. This is why canonical JSON representations used in signing schemes specify a key order. Sorted formatted JSON is also easier to scan for one specific key, because your eye can run down the alphabetical sequence instead of reading every line.

Big integers

JSON has no integer type distinct from number, and JavaScript numbers are IEEE-754 doubles. Any integer above 2^53 − 1 (9007199254740991) loses precision on parse. Database IDs and snowflake identifiers routinely exceed that. The large-integer option rewrites long numeric literals as strings before parsing so they survive formatting intact — but remember that the resulting document is no longer the same JSON, so use it for inspection rather than for round-tripping.

The JSON tree view for large payloads

Formatting a document makes it readable; a tree view makes it navigable. Collapsing and expanding nested objects and arrays lets you explore a deep API response without scrolling through thousands of lines of pretty-printed text. When a payload contains a data array with five hundred records, the JSON tree view folds it away, lets you open exactly one record to inspect its fields, and folds it back — something no amount of indentation makes pleasant.

The tree view also labels every node with its type and, for arrays, its length. That is usually enough to answer "why is this payload so large?" without any further tooling, and it doubles as a JSON viewer when you only need to look, not edit.

Format, validate and inspect in one place

The whole loop — format JSON, validate JSON, sort keys, explore the tree, copy or download the result — runs in your browser with no upload. That privacy detail matters more than it sounds: real payloads contain auth tokens, user records and internal endpoint names that have no business travelling to a third-party server. A JSON formatter is a small tool, but a client-side JSON formatter is a small tool that cannot leak anything.

Common situations where a JSON formatter saves the day:

• An API returns a wall of minified JSON and you need to find one field inside it.
• A config file fails to load and the runtime error message is useless.
• A webhook body needs to be inspected before you trust it.
• Two versions of a document need comparing after sorting keys.
• A large response needs to be navigated rather than read end to end.