Skip to main content

JSON Formatter & Validator

Paste JSON to instantly format, minify, and validate it. See key count, nesting depth, and root data type.

Ad (leaderboard)
Status
Keys
Depth
Type
Rate this tool
0.0 / 5 · 0 ratings

Embed This

Add this calculator to your website for free. Copy the single line of code below and paste it into your HTML. The calculator auto-resizes to fit your page.

<script src="https://calchammer.com/embed.js" data-calculator="json-formatter" data-category="everyday"></script>
data-theme "light", "dark", or "auto"
data-values Pre-fill inputs, e.g. "amount=1000"
data-max-width Max width, e.g. "600px"
data-border "true" or "false"
Or use an iframe instead
<iframe src="https://calchammer.com/embed/everyday/json-formatter" width="100%" height="500" style="border:none;border-radius:12px;" title="Json Formatter Calculator"></iframe>

Preview

yoursite.com/blog
Json Formatter Calculator auto-resizes here
Ad (in_results)

What this formatter is, and is not

This tool parses your input as strict JSON per RFC 8259, then re-emits it with the indentation you choose. That is the entire job. It does not:

  • Accept JSON5 (comments, single quotes, unquoted keys, trailing commas). These will fail validation. If your input is a config file with comments, strip them first or use a JSON5 parser instead.
  • Accept JSONC (JSON-with-comments, as used in tsconfig.json). Same story.
  • Send your input anywhere. Parsing runs in your browser via the platform's JSON.parse. Nothing is uploaded.
  • Preserve number precision beyond JavaScript's IEEE-754 double. If your input has integers larger than 253, they will round. This is a JSON spec ambiguity, not a tool bug — see "Edge cases" below.

The five errors that account for most invalid JSON

After validating a lot of JSON over the years, the same five mistakes come up over and over. In rough order of frequency:

  1. Trailing comma. {"a": 1, "b": 2,} is valid JavaScript and invalid JSON. The parser stops at the comma after 2. The fix is removing it. Some downstream tools (the jq CLI, JSON.parse in browsers) all reject this.
  2. Single quotes instead of double quotes. {'a': 1} is not JSON. Keys and string values must be double-quoted. This is the most common mistake when copy-pasting from Python code or JavaScript object literals.
  3. Unquoted keys. {a: 1} is valid JavaScript but not JSON. Keys must always be strings, double-quoted.
  4. Unescaped control characters in strings. A literal newline inside a string value ({"msg": "line1
    line2"}
    ) is invalid. Newlines must be escaped as \n. The same applies to tabs, carriage returns, and other control characters.
  5. Comments. JSON has no comment syntax. // like this and /* or this */ both fail. If you need comments in a JSON file, your downstream consumer needs to support JSONC or JSON5; vanilla JSON does not.

Edge cases this handles correctly

  • Empty objects and arrays. {} and [] are valid. So is a single bare value: 42, "hello", true, null. RFC 8259 §2 allows any value as the root.
  • Unicode escapes. "é" and "é" are the same string after parsing. The formatter preserves whichever form your input used in the output (most browsers will re-emit it as the literal character).
  • Numeric precision. JSON numbers are spec'd as decimal — there is no explicit integer/float distinction. A number like 9007199254740993 (253 + 1) is technically valid JSON but will round to 9007199254740992 when parsed by anything using IEEE-754 doubles (which is most things, including JSON.parse). For integers larger than 253, encode them as strings.
  • Deeply nested structures. The formatter walks recursively; the limit is browser stack depth (typically 1000+ levels), which is well past any reasonable use case.

When minification actually matters

Stripping whitespace from JSON typically saves 20-40% of bytes on real-world payloads. The arithmetic on whether that is worth doing depends on where the payload lives:

  • HTTP API responses with Content-Encoding: gzip (or br): gzip already eliminates most of the redundancy that whitespace adds. The minified-vs-pretty difference after compression is usually under 5%. Not worth the readability tradeoff; serve pretty-printed and let gzip do its job.
  • Static JSON files served without compression: minification can genuinely halve transfer size. Minify before deploying.
  • JSON embedded in HTML (e.g., bootstrapping data for a single-page app via <script type="application/json">): minify. The HTML gets gzipped together with the JSON, but reducing the source size still helps Time-to-Interactive on slow networks.
  • JSON stored in a database column (Postgres jsonb, etc.): irrelevant. The storage layer canonicalizes the representation and ignores your whitespace anyway.

Converting to or from other formats

Often what you actually want is not JSON-to-JSON but JSON-to-something-else. Use the format-specific converters: JSON to YAML, JSON to CSV, JSON to TypeScript, YAML to JSON, CSV to JSON, XML to JSON. For multi-language source minification (JS/CSS/HTML, not JSON), the code minifier handles those formats; for stable hash digests of canonical JSON, see the hash generator.

Related Calculators

You Might Also Need

Disclaimer: This calculator is for informational and educational purposes only. Results are estimates and should not be considered professional expert advice. Consult a qualified professional before making decisions based on these calculations. See our full Disclaimer.

Recommended Reading