JSON Formatter Calculator

Understanding the JSON Formatter Calculator

A JSON formatter validates input, reports its structure, and pretty-prints it with indentation. Validation is the part that earns its keep, because the errors JSON parsers reject are a short and predictable list that catches people out repeatedly.

How it actually works

Paste JSON text. The tool parses it, and on success reports whether the top level is an object or array, counts top-level keys or items, and returns the formatted output with two-space indentation. On failure it reports the parser's error message rather than a generic failure.

The deeper context most people miss

Every item in that list is legal in JavaScript object literals, which is the single biggest source of invalid JSON. JSON was derived from JavaScript syntax but is a strict subset, and the differences catch people who assume that anything valid in JavaScript will parse as JSON.

What JSON actually permits, and the edge cases

The specification is deliberately small. Values may be objects, arrays, strings, numbers, true, false, or null. Keys must be strings in double quotes. Strings must use double quotes, with specific escape sequences for quotes, backslashes, and control characters, and Unicode escapes written as four hex digits. Numbers follow a defined grammar that excludes several things people assume are permitted: leading zeros, a leading plus sign, hexadecimal notation, and the special values Infinity and NaN, which are all legal in JavaScript and all invalid in JSON. That last one causes real problems, since serialising a JavaScript object containing NaN or Infinity produces null rather than an error, which silently corrupts data. Duplicate keys are technically not forbidden by the specification but behaviour is undefined and parsers differ, with most keeping the last occurrence, so relying on it is unsafe. Large integers are a well-known hazard: JSON has no integer type distinct from floating point, and parsers using IEEE 754 doubles lose precision above about 9 quadrillion, which is why systems handling large identifiers frequently transmit them as strings. Trailing content after the top-level value is invalid. An empty document is invalid. Byte order marks at the start of a file cause parse failures in many parsers and are a recurring source of confusing errors, particularly with files saved from Windows editors.

A worked example: reading a parser error

A parser reporting an unexpected token at a position is more informative than it appears, and the position is where the parser gave up rather than necessarily where the mistake is. A trailing comma before a closing brace typically reports the error at the brace, since the parser expected another key after the comma and found the closing character instead, so the fix is usually one token earlier than the reported position. An unexpected end of input generally means an unclosed brace, bracket, or string somewhere earlier, and for a long document that means finding the imbalance rather than looking at the end. An unexpected token at position zero usually means a byte order mark or leading whitespace containing something unexpected. A string that terminates unexpectedly frequently indicates an unescaped quote or backslash inside it, and Windows file paths are the classic case since single backslashes are invalid escape sequences. The practical debugging approach for a large document is bisection: cut it in half, test each half, and narrow to the offending region, which is far faster than reading through. Editors with JSON language support catch most of these while typing and are worth using for any hand-edited configuration, since hand-editing is where these errors originate and machine-generated JSON is rarely malformed.

Deciding when JSON is the wrong format

JSON became ubiquitous for good reasons: it is simple, human-readable, universally supported, and maps cleanly onto the data structures of most languages. It suits API payloads, configuration where comments are not needed, and interchange between systems. It suits several things poorly. Configuration files are the most common mismatch, since JSON forbids comments, which makes documenting configuration awkward, and its strictness about trailing commas makes editing lists tedious, which is why YAML, TOML, and JSON5 exist and why many tools have adopted them for config specifically. Large datasets are poorly served, since JSON must generally be parsed in full before use, and formats supporting streaming or columnar access perform far better at scale, with newline-delimited JSON being a common compromise that allows line-by-line processing. Binary data has no native representation and must be base64 encoded, inflating size by a third. Dates have no type, so they are conventionally ISO 8601 strings and require application-level handling. Precise decimal values including money are hazardous given the floating point issue, and are frequently transmitted as strings or as integer minor units. Schema validation is not built in, which JSON Schema addresses as a separate specification. For high-volume machine-to-machine communication, binary formats including Protocol Buffers and MessagePack offer substantially smaller payloads and faster parsing at the cost of human readability.

Formatting, minification, and why both exist

Pretty-printing with indentation and minification stripping all optional whitespace produce identical data and serve opposite purposes. Formatted JSON is for humans, making structure visible and diffs meaningful in version control, which matters considerably since a minified file produces a single-line diff on any change while a formatted one shows exactly what altered. Minified JSON is for transmission, removing bytes that carry no information, and the saving is meaningful over a network, though HTTP compression reduces the difference substantially since whitespace compresses extremely well. The practical convention is to store and version formatted JSON and to minify at transmission, with most web servers handling compression automatically. Key ordering is a related consideration: JSON objects are unordered by specification, but most parsers and serialisers preserve insertion order in practice, and sorting keys consistently makes diffs cleaner and enables byte-level comparison of semantically identical documents, which matters for caching and integrity checking. Canonical JSON specifications exist for cases requiring a deterministic byte representation, such as signing. Indentation width is purely convention, with two spaces being the most common and four also widespread. Trailing newlines at end of file matter for some tooling. None of these affect the data and all of them affect how pleasant the file is to work with.

Variations: JSON5, JSONC, YAML, and streaming formats

Several formats extend or replace JSON for specific weaknesses. JSON5 permits comments, trailing commas, single quotes, unquoted keys, and additional number formats, addressing the configuration use case directly while remaining recognisably JSON. JSONC, JSON with comments, is used by several tools including some editors for configuration. YAML is a superset of JSON with a considerably more permissive and more complex syntax, supporting comments, references, and multi-line strings, at the cost of surprising behaviours including the well-known issue where unquoted values such as country codes and version numbers can be parsed as unintended types. TOML targets configuration with a simpler and more predictable grammar. Newline-delimited JSON, sometimes called JSON Lines, places one JSON value per line, which enables streaming and append-only writing and is widely used for logs and datasets. JSON Schema provides validation and documentation as a separate layer. For binary interchange, Protocol Buffers, MessagePack, Avro, and CBOR all offer compactness and speed with schema requirements or loss of human readability, and the choice between them and JSON is usually about whether human inspection matters more than payload size.

Working with JSON reliably

Check for the four common invalidities first when a parse fails: trailing commas, single quotes, comments, and unquoted keys, all of which are legal JavaScript and invalid JSON. Read the parser error position as where parsing stopped rather than where the mistake is, since a trailing comma reports at the following brace and the fix is usually one token earlier. Bisect large documents to locate errors rather than reading through them. Use an editor with JSON language support for hand-edited files, since that is where malformed JSON originates. Transmit large integers and precise decimals as strings, since JSON has no integer type and parsers using doubles lose precision above roughly 9 quadrillion. Store formatted JSON in version control and minify at transmission, since formatted files produce meaningful diffs while minified ones produce single-line changes. Sort keys consistently where deterministic output matters. And choose a different format for configuration needing comments, for large streaming datasets, or for high-volume binary interchange.

What people get wrong

• Assuming anything valid in JavaScript is valid JSON, when trailing commas, single quotes, comments, and unquoted keys are all legal JavaScript and rejected by JSON parsers.
• Looking at the reported error position for the mistake, when a trailing comma reports at the following brace and the actual fix is typically one token earlier.
• Transmitting large integers as numbers, when JSON has no integer type and parsers using IEEE 754 doubles lose precision above roughly 9 quadrillion.
• Storing minified JSON in version control, which produces a single-line diff on any change and makes review effectively impossible.

Where the math comes from

The tool parses the input with a standard JSON parser, reports the top-level type as object or array with a count of keys or items, and re-serialises with two-space indentation. Parsing either succeeds completely or fails with an error indicating the position at which the parser could not continue, which is where parsing stopped rather than necessarily where the error was introduced.

Questions and answers

Related calculators

Gift Card Value · Tattoo Cost · Shoe Size Converter · Holiday Lights · Web Bandwidth