JSON Formatter: The Complete Guide to Format, Validate & Debug JSON

JSON (JavaScript Object Notation) is a data format defined by RFC 8259. A JSON formatter takes JSON text and rewrites its whitespace — indentation, line breaks, spacing around punctuation — without touching the data it represents. Whether you call it a JSON formatter, a JSON beautifier, a JSON viewer, or you just want to format JSON online because a browser tab is faster than opening an editor, it's the same job: {"id":1,"active":true} and a neatly indented version of it are the same document. Every key, value, and structural relationship is identical — only the presentation changed.

Two directions fall out of that one job:

• Beautify (pretty-print): add indentation and line breaks so nesting is visible at a glance — what you want after pasting a minified API response out of DevTools.
• Minify (compact): remove every byte of insignificant whitespace — what you want before checking a JSON fixture into a test suite, or when measuring the actual payload size a client downloads.

A formatter can only do either safely once it knows the input is syntactically valid JSON, which is why a competent JSON formatter online — this one included — runs your input through a real parser first rather than doing find-and-replace on whitespace.

JSON has been standardized twice, by two different bodies, kept intentionally in sync — so "valid JSON" is a well-defined, testable property, not a matter of opinion or one browser's quirks.

• RFC 8259 — "The JavaScript Object Notation (JSON) Data Interchange Format," published by the IETF in December 2017. It obsoletes RFC 7159, which itself succeeded the original RFC 4627 authored by Douglas Crockford, who popularized JSON in the early 2000s as a way to pass structured data between a browser and a server without the ceremony of XML. RFC 8259 additionally carries the designation STD 90 — IETF Internet Standard status, the highest maturity level a specification can reach in that process.
• ECMA-404 — "The JSON Data Interchange Syntax,"published by Ecma International (the same body behind ECMA-262, the JavaScript language spec). It describes only the grammar; RFC 8259 goes further and also covers interoperability pitfalls — like the number-precision issue covered later in this guide — and security considerations a pure syntax spec doesn't need to address.

A correctly built formatter validates against that formal grammar — not against "whatever eval()would accept," which is the trap a lot of older, informal JSON tools fell into.

JSON has exactly six value types, and every valid document is one value built recursively out of those six:

JSON Value
├─ Object   unordered key/value pairs — keys must be strings
├─ Array    ordered list of values
├─ String   double-quoted Unicode text
├─ Number   integer or float, no leading zeros
├─ Boolean  true or false
└─ Null     the literal null

An object's values and an array's elements can themselves be
any JSON value — including more objects and arrays.

A few rules trip people up constantly because they're borrowed from JavaScript object literals but aren't legal in strict JSON:

{
  id: 7421,                       // keys MUST be double-quoted strings
  'name': 'Ava Chen',             // single quotes are never valid in JSON
  "active": True,                 // booleans are lowercase: true / false
  "roles": ["admin", "editor",],  // trailing comma before ] is invalid
  "manager": undefined,           // undefined does not exist in JSON — use null
  "score": 01.50,                 // leading zeros before a decimal are invalid
}

• Object keys are always strings — {1: "a"} is invalid; it must be {"1": "a"}.
• Numbers cannot have leading zeros, a leading +, or be NaN, Infinity, or hexadecimal — only base-10 decimal notation, with an optional -, a fraction, and an exponent.
• Control characters inside a string must be escaped: \n, \t, \", \\, \uXXXX.
• Trailing commas are never allowed in strict JSON, even though they're legal in JavaScript object/array literals and in JSON5.
• Comments do not exist in JSON, in any position — this is what makes a tsconfig.json technically JSONC, not JSON.

These terms get used almost interchangeably in search results, which is why so many competing pages hedge instead of answering the question directly. Here's the distinction, stated plainly:

If you searched "json validator"expecting a syntax check — is this parseable at all — rather than schema validation, this page's formatter is what you want: parsing is built in, and failures are located by line and column. GenKitLab keeps the heavier question separate:

• JSON Formatter & Validator handles formatting, minifying, and syntax validation.
• JSON Schema Validator answers the separate, heavier question: does this valid JSON match the shape a JSON Schema describes — required fields, correct types, no ignored keywords.

JSON tooling means something slightly different depending on where you sit in the stack.

• Backend & API developers — beautify a raw response body from curl or a REST client to actually reason about nested objects and array lengths, then run a JSON Diff against a saved "golden" response instead of eyeballing minified text for a missing field.
• Frontend developers— turn an API's raw JSON shape into something the type system understands: JSON to TypeScript gets a starting interface in seconds; for runtime validation too, JSON to Zod generates a schema you can call .parse() on.
• QA & test engineers— minify large fixtures to keep repo diffs small; beautify with sorted keys the moment a test fails and you need to visually diff "expected" against "actual" without key-order noise. JSONPath Tester extracts a single deeply nested field for an assertion without a chain of bracket lookups.
• DevOps & platform engineers — hand-edited config (Terraform outputs, Kubernetes manifests, CI payloads) is prone to trailing commas and stray quotes; machine-generated JSON needs minifying before it fits an environment variable. CSV to JSON turns a spreadsheet export of hosts or feature flags into something automation can consume.
• Technical writers — beautify a raw API response with consistent 2-space indentation before it goes into documentation, and validate first so readers never copy-paste an example that fails.

An online tool is right for a one-off paste. It's the wrong tool the moment formatting needs to run in a script, a git hook, or a CI step — which is usually what someone searching json formatter python actually needs: the code, not another browser tab.

Python: json.dumps

import json

with open("data.json") as f:
    data = json.load(f)

# indent=2 pretty-prints; sort_keys=True gives a stable, diffable output
print(json.dumps(data, indent=2, sort_keys=True))

json.load raises json.decoder.JSONDecodeError on invalid input, with .lineno, .colno, and .posattached — enough to build the same “exactly where it broke” message a good formatter shows you. For a one-liner with no script file, Python ships a CLI for this too:

python -m json.tool data.json
python -m json.tool --sort-keys data.json   # add key sorting
python -m json.tool --compact data.json     # minify instead of pretty-print

JavaScript: JSON.stringify

const data = JSON.parse(rawJson);

// second arg is a "replacer" (null = include everything); third is the indent
console.log(JSON.stringify(data, null, 2));

JSON.parse throws a SyntaxErroron invalid input, but the message isn't standardized across engines — V8 (Chrome, Node), SpiderMonkey (Firefox), and JavaScriptCore (Safari) each phrase it differently, and a trailing comma comes back from V8 with no position at all. That inconsistency is exactly why a formatter with its own error locator is worth using over raw engine output. The replacer argument also drops or renames keys on the way out:

JSON.stringify(data, (key, value) => (key === "password" ? undefined : value), 2);

Sorting keys for a stable diff

Object key order carries no semantic meaning in JSON, so sorting it recursively before diffing two payloads eliminates false-positive changes that are really just key-order noise. Array order is left alone in every case below — array position is data, not formatting:

function sortKeys(value) {
  if (Array.isArray(value)) return value.map(sortKeys);
  if (value !== null && typeof value === "object") {
    return Object.keys(value)
      .sort()
      .reduce((acc, k) => ({ ...acc, [k]: sortKeys(value[k]) }), {});
  }
  return value;
}
console.log(JSON.stringify(sortKeys(data), null, 2));

print(json.dumps(data, indent=2, sort_keys=True))

jq -S '.' response.json

Command line: jq

cat data.json | jq .          # pretty-print with syntax highlighting
cat data.json | jq -S .       # pretty-print with keys sorted
cat data.json | jq -c .       # compact (minify)

jq .alone validates and pretty-prints in one shot — it exits non-zero and prints a parse error to stderr if the input isn't valid JSON.

Two separate bugs live in this one example, easy to conflate but worth telling apart:

{
  "eventId": 714341252076979033,
  "eventId": "duplicate-key-example",
  "payload": { "ok": true }
}

{
  "eventId": "duplicate-key-example",
  "payload": { "ok": true }
}

First, this document has a duplicate key. That's not a syntax error — RFC 8259 permits it syntactically — but the behavior is implementation-defined, and every mainstream parser, including JSON.parse, silently keeps only the last occurrence and discards the earlier one. The numeric value is gone, with no warning.

Second, and separately: if that first eventId had been the only one, JSON.parse would have converted 714341252076979033 into a JavaScript number — and because JavaScript numbers are IEEE-754 doubles with a safe-integer ceiling of Number.MAX_SAFE_INTEGER (9007199254740991, i.e. 2^53 − 1), this 19-digit ID exceeds that ceiling and would have silently rounded to 714341252076979072, with no error thrown. The next section covers this precision bug in full.

const parsed = JSON.parse('{"eventId": 714341252076979033}');
console.log(parsed.eventId); // 714341252076979072 — wrong, no error

# Python's int type is arbitrary-precision, so json.loads keeps the exact
# integer. (Python floats are still IEEE-754 doubles — this immunity is
# specific to integers, not to JSON numbers generally.)
import json
parsed = json.loads('{"eventId": 714341252076979033}')
print(parsed["eventId"])  # 714341252076979033 — exact

JSON's grammar is stricter than the JavaScript object literal syntax it resembles. Almost every "why won't this parse" question traces back to one of a few causes:

The exact wording, engine by engine

The same underlying mistake reads completely differently depending on where it's thrown:

One more failure mode is worth knowing, because it isn't a syntax error and no formatter will flag it: large integers. JSON numbers have no fixed precision limit, but JavaScript's number type does — anything past 2^53 (about 9 quadrillion) can come back rounded after a JSON.parse → JSON.stringify round trip. A 64-bit database ID or a Snowflake ID is exactly the kind of value this bites — the next-but-one section covers it in full.

Two distinct, real risks — and one popular misconception worth correcting.

Prototype pollution — correctly explained

Here's the misconception: many people believe that parsing {"__proto__": {"isAdmin": true}}directly modifies an object's prototype chain. It does not. Try it:

const parsed = JSON.parse('{"__proto__": {"isAdmin": true}}');
console.log(Object.getPrototypeOf(parsed) === Object.prototype); // true — unchanged
console.log(parsed.hasOwnProperty("__proto__")); // true — it's a normal own property!
console.log(parsed.__proto__); // { isAdmin: true } — just a regular value under a weird key

JSON.parse treats __proto__ as nothing more than a string key. The result is a perfectly ordinary object that happens to have an own property literally named __proto__— it does not touch the object's actual prototype.

The real vulnerability shows up one step later, and only if that parsed object is then fed into an unsafe deep-merge or deep-clone utility — one that recursively copies properties from a source object onto a target object, including a key named __proto__, without guarding against it. In that scenario, the merge function can end up doing the equivalent of target.__proto__.isAdmin = true, which does reach into Object.prototype — polluting every plain object in the running process, including ones that have nothing to do with the original payload. The fix lives in the merge/clone utility, not in JSON.parse itself: explicitly reject __proto__, constructor, and prototype as keys during recursive assignment, or build the target object with Object.create(null) (no prototype to pollute) or a Map when merging untrusted data.

Where your JSON actually goes

Ask this before pasting a production API response, an auth token, or a customer record into any web tool — it's the right instinct, and most tool pages don't answer it directly. In November 2025, watchTowr Labs reported that two long-standing, widely used online JSON tools — jsonformatter.org and codebeautify.org — had been storing user-submitted content through a "Recent Links" save/share feature with predictable, enumerable URLs. That exposed more than 80,000 snippets — roughly five years of JSONFormatter history and a year of CodeBeautify's — to anyone who crawled the URL pattern, including live AWS access keys, GitHub personal access tokens, database passwords, and other credentials people had pasted in for formatting. watchTowr also planted canary AWS credentials on both sites and reported active scrapers attempting to use them within 48 hours. Per that reporting, both platforms appear to have quietly disabled the save/share feature — likely in response to watchTowr's outreach — but watchTowr says many of the organizations it tried to notify about their own exposed data never responded.

This is the practical argument for a client-side tool, not a theoretical one. If a formatter processes your input on a server — even one with good intentions — that input has, at minimum, crossed the network and touched infrastructure you don't control, and history shows "we don't store it" is not always true in practice. For GenKitLab's JSON formatter, specifically: everything runs client-side. Parsing, formatting, minifying, key sorting, and error location all happen in JavaScript in your browser tab — there is no network request that carries your pasted content anywhere. Verify it yourself in under a minute: open DevTools, switch to the Network tab, paste a payload, format it — no request fires. That verifiability matters more than the claim itself, because there's no server-side code path that could leak the payload even by accident. Be more careful with tools that bundle formatting into a larger "editor" product with sync, sharing, or account features — the more a tool does beyond pure local formatting, the more likely some part of it touches a server.

This is the JSON bug most likely to cost you a debugging session, precisely because it never throws an error.

JSON.parse converts every bare JSON number into a native JavaScript number — always an IEEE-754 double-precision float, even when the source value was logically an integer. Doubles can represent integers exactly only up to Number.MAX_SAFE_INTEGER (9007199254740991, i.e. 2^53 − 1). Beyond that ceiling, some integers simply have no exact double representation, and the nearest one gets silently substituted — no error, no warning. This is exactly the shape of bug that hits 64-bit database primary keys, Snowflake-style distributed IDs, and social-platform status IDs — anything generated as a large integer on a backend that doesn't think in JavaScript-number terms, then passed through a JS-based API layer or frontend.

Two real fixes, both used in production systems:

• A reviver function on JSON.parsecan intercept and convert specific fields before they're used — but it works reliably only when combined with a parser that preserves the original digit string, since the native reviver alone receives the already-rounded double for a plain numeric literal. It cannot recover precision that's already lost by the time it runs.
• Emit the value as a quoted string at the source— the reliable fix. A quoted numeral is never numerically parsed, so it's never rounded:

{ "id": "714341252076979033", "name": "example" }

const parsed = JSON.parse('{"id": "714341252076979033", "name": "example"}');
console.log(parsed.id); // "714341252076979033" — exact, because it's a string
console.log(BigInt(parsed.id)); // 714341252076979033n — convert only when you need to do math

If you control the API or database layer emitting these IDs, quoting them at the source is the fix that actually holds up across every consumer — browsers, Node, and any other JSON parser downstream — because it removes the ambiguity at the format level instead of trying to patch around it after the fact.

JSON itself has no built-in way to say "this field is required" or "this string must be an email address." JSON Schema is the widely adopted vocabulary for describing exactly that — the shape, types, and constraints a JSON document must satisfy — so tooling can validate data automatically instead of relying on someone reading documentation carefully.

The current stable version is Draft 2020-12, published at json-schema.org. A few notable changes from the prior 2019-09 draft, if you're maintaining schemas written against an older version:

• Tuple-style array validation moved from items/additionalItems to prefixItems (fixed-position entries) combined with items (anything after).
• $recursiveRef and $recursiveAnchor were replaced by $dynamicRef and $dynamicAnchor, a more flexible mechanism for self-referencing schemas.
• unevaluatedProperties and unevaluatedItems moved into their own required vocabulary, rather than being bundled implicitly with the core spec.

A minimal example — a schema describing the sorted user object from the key-sorting example above:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "requestId": { "type": "string" },
    "user": {
      "type": "object",
      "properties": {
        "id": { "type": "integer" },
        "active": { "type": "boolean" },
        "roles": { "type": "array", "items": { "type": "string" } }
      },
      "required": ["id", "active"]
    }
  },
  "required": ["requestId", "user"]
}

Formatting and validating raw JSON syntax is a separate, earlier step from schema validation — you need syntactically valid JSON before a schema validator can even begin checking its shape. Once your syntax is clean, GenKitLab's JSON Schema Validator checks a document against a schema like the one above and reports every failure by JSON Pointer, so you know exactly which field violated which rule.

None of these formats is objectively "best" — they trade off differently, and picking the wrong one for the job (not the format itself) is usually the actual problem.

The honest read: a VS Code extension is genuinely the better tool when you're already editing a file in your project — offline, integrated, fast. It's not built for "I have a blob of JSON in my clipboard right now, from a terminal or a Slack message, and I need it readable in the next five seconds" — that specific gap is what a browser-based formatter fills, which is exactly why the storage practices of that category of tool matter so much: you're often pasting real production data into it.

For JSON that already lives in a file, reaching for a browser tab is usually one step too many — this is the json formatter vscode question. VS Code formats JSON natively:

• Format Document: Shift+Alt+F (Windows/Linux) or Shift+Option+F (macOS) — no extension required.
• Format on save: set "editor.formatOnSave": true in settings.json, scoped to JSON only if you don't want it everywhere.

{
  "[json]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "vscode.json-language-features"
  }
}

VS Code's JSON language service can also attach a schema to a file (via $schema, or the json.schemas setting) for inline validation and autocomplete while typing — the editor equivalent of what a schema validator tool does after the fact.

This formatter is one piece of a JSON toolchain — GenKitLab runs a full JSON tools category, all client-side, all free:

• JSON Schema Validator — validate structure against a JSON Schema, with every failure located by JSON Pointer.
• JSON Diff & Compare — compare two documents structurally, so reformatting and key order are ignored.
• JSON Minifier — the dedicated minify-only tool, with an exact byte-savings readout.
• JSON to TypeScript — generate TypeScript interfaces from a JSON sample.
• JSONPath Tester — run a JSONPath expression against a document and see every matching node.
• JSON ↔ CSV Converter — convert either direction with nested-object flattening.

And for JSON embedded in other formats: JWT Decoder decodes the JSON header and payload inside a token, Base64 Encoder & Decoder unwraps base64-encoded JSON blobs from cookies and query strings, and Regex Tester is useful for scrubbing or extracting values out of raw JSON text before it's valid enough to parse.

1. Bray, T., Ed. The JavaScript Object Notation (JSON) Data Interchange Format. RFC 8259 / STD 90. Internet Engineering Task Force, December 2017.
2. Ecma International. ECMA-404: The JSON Data Interchange Syntax, 2nd edition.
3. Mozilla Developer Network. "JSON.parse()." MDN Web Docs.
4. Mozilla Developer Network. "BigInt." MDN Web Docs.
5. JSON Schema Organization. "Specification: Draft 2020-12." json-schema.org.
6. watchTowr Labs (research by Jake Knott). Findings on 80,000+ exposed user-submitted files — including live credentials — on jsonformatter.org and codebeautify.org, reported November 25, 2025, via The Hacker News: "Years of JSONFormatter and CodeBeautify Leaks Expose Thousands of Passwords and API Keys."