JSON Beautifier & Validator — Free Online Tool

What is JSON Formatter, Validator & Converter?

A JSON formatter re-serialises a parsed JSON document with consistent indentation and line breaks, which is a lossless operation: the bytes change, the data model does not. This tool parses your input with the browser's own JSON.parse, so what it accepts is exactly what a JavaScript runtime accepts, then re-emits it through JSON.stringify with the indent you pick — or refuses and tells you the line and column where parsing stopped.

• Beautify, Minify, Validate: Beautify pretty-prints with the chosen indent. Minify emits the same value with no whitespace at all. Validate parses without producing output, so you can check a 5 MB payload without waiting for it to render.
• Seven indent choices: The Indent dropdown offers 2, 3 and 4 spaces plus 1, 2, 3 and 4 tabs. Space widths are passed to JSON.stringify as a number; tab options are passed as a literal tab string, which is how you get real tab characters rather than spaces.
• Sort keys: Tick Sort keys and every object is rebuilt with Object.keys().sort() applied recursively, including objects nested inside arrays. That is UTF-16 code-unit order, so uppercase letters sort before lowercase and "10" sorts before "9".
• Convert to five formats: The Convert to dropdown re-emits the same parsed value as JSON, YAML, CSV, XML or TOML. Changing the dropdown re-renders immediately — you do not have to press Convert again — and the output pane switches its syntax highlighting to match.
• Tree view: The Tree button opens a collapsible viewer of the parsed structure, which is the fastest way to answer "what shape is this response?" for a deeply nested API payload without scrolling through thousands of formatted lines.

Why use the JSON formatter?

Minified JSON is unreadable to humans and a single misplaced character makes a whole document unparseable, so formatting and validating are the two things you actually need when a payload does not behave.

• The error tells you where, not just what: V8 reports a byte offset, which is useless in a one-line 40 KB response. This tool converts that offset into a line and column: "Expected ',' or '}' after property value in JSON at position 7 (line 1, col 8)". Formatting first, then re-validating, turns a hunt into a jump.
• Sorted keys make diffs meaningful: Two servers can emit the same object with different key order, and a line diff of that is pure noise. Beautify with Sort keys on both sides and the diff shrinks to the values that actually differ — the standard trick for comparing config snapshots or API fixtures.
• Minify before you measure: Formatted JSON carries indentation bytes that never reach production. Minify to see the real payload size, and remember that gzip or Brotli compresses repeated whitespace extremely well, so pretty-printing costs less over the wire than the raw byte count suggests.
• Format shifting without a script: Turning a JSON fixture into YAML for a Kubernetes manifest, CSV for a spreadsheet, or TOML for a config file is a five-second dropdown change instead of a throwaway script and a dependency install.
• Nothing is uploaded: Parsing, sorting and conversion all run in the page. API responses containing tokens, PII or internal hostnames stay on your machine, which is the difference between a debugging habit you can use at work and one you cannot.

When to use the JSON formatter

Reach for it whenever JSON is unreadable, rejected, or in the wrong shape for the next tool in the chain.

• Debugging an API response copied out of a network panel or a curl run, where the whole document is one line and you need to find a specific field.
• Chasing down a parse error in a package.json, tsconfig.json, .eslintrc.json or a CI job definition after a hand edit — the error location is usually a trailing comma or a comment.
• Comparing two payloads that should be identical: beautify both with Sort keys enabled, then diff.
• Checking payload size before and after a change, by minifying and reading the character count.
• Turning a JSON fixture into YAML for a Helm values file or Docker Compose file, or into CSV to hand to someone who works in a spreadsheet.
• Exploring an unfamiliar third-party response with the Tree view to learn its nesting depth and field names before writing types against it.
• Verifying that a log line, a webhook body, or a database JSON column is well-formed before you blame your own parser.

How to use the JSON formatter

Everything happens in one screen: paste on the left, choose options above, press an action, read the result on the right.

1. Paste or upload your JSON: Type or paste into the "JSON in" pane, or press Upload .json to load a file from disk (the picker accepts .json and plain text). The status line confirms the filename.
2. Pick an indent: Choose 2, 3 or 4 spaces, or 1–4 tabs. Two spaces is the near-universal default for JSON files in JavaScript projects; tabs are the right pick if your editor config or team style guide uses them.
3. Optionally tick Sort keys: This normalises key order recursively before output. Turn it on when you plan to diff the result, and off when key order carries meaning you want to preserve visually.
4. Press Beautify, Minify or Validate: Beautify formats, Minify strips all whitespace, Validate only reports "✓ Valid JSON" or the parse error with its line and column. If the input is broken, all three report the same location.
5. Convert if you need another format: Set Convert to YAML, CSV, XML or TOML and the output updates live. CSV expects an array of flat objects; XML wraps a top-level array as <root><item>…</item></root> so the document stays single-rooted.
6. Open the Tree view to explore: Press Tree for a collapsible node view of the parsed value, with a copy control for the pretty-printed form. Useful when you want structure rather than text.

Key features

• Exact error location: The raw V8 message is kept and a computed (line, col) appended, so "Unexpected number in JSON at position 20" becomes something you can navigate to.
• Recursive key sorting: Sort keys walks arrays and nested objects, not just the top level, so the whole document is normalised in one pass.
• Five output formats: JSON, YAML, CSV, XML and TOML from one parsed value, with the output pane's highlighting switching to match the chosen format.
• Tab-or-space indentation: Seven presets covering 2/3/4 spaces and 1/2/3/4 tabs. Tabs are emitted as real U+0009 characters, not expanded.
• File upload: Load a .json file straight from disk instead of pasting, which avoids clipboard size limits on very large documents.
• Collapsible tree viewer: A structural view of the parsed value in a dialog, with one-click copy of the formatted JSON.

Common use cases

• API debugging: Format a minified response to find the one field that is null, missing, or a string where you expected a number.
• Config file repair: Locate the trailing comma, smart quote, or stray comment that makes a tooling config fail to load.
• Fixture normalisation: Beautify with sorted keys before committing test fixtures so future diffs show real changes rather than reordering.
• Payload budgeting: Minify to measure the byte cost of a response shape before and after adding fields.
• Config format migration: Convert a JSON settings file to YAML or TOML when moving between tools that prefer different formats.
• Reporting and analysis: Convert an array of records to CSV so it can be opened in a spreadsheet or loaded into a BI tool.

Examples

Real input and output pairs from this tool. Indent is 2 spaces unless the note says otherwise.

{"id":42,"name":"widget","tags":["a","b"],"meta":{"active":true,"count":3}}

{ "id": 42, "name": "widget", "tags": [ "a", "b" ], "meta": { "active": true, "count": 3 }
}

{"zulu":1,"Alpha":2,"bravo":{"z":1,"a":2}}

{ "Alpha": 2, "bravo": { "a": 2, "z": 1 }, "zulu": 1
}

{ "a": 1, "b": 2,
}

Expected double-quoted property name in JSON at position 22 (line 4, col 1)

{"name":"widget","tags":["a","b"],"meta":{"active":true,"count":3}}

name: widget
tags: - a - b
meta: active: true count: 3

[{"id":1,"name":"Ada"},{"id":2,"name":"Linus"}]

id,name
1,Ada
2,Linus

Technical reference

The rules the parser and serialiser follow:

Specification

RFC 8259 (December 2017, obsoletes RFC 7159); the same grammar is standardised as ECMA-404

Value types

Six: object, array, string, number, true/false, null. No date, no binary, no comment syntax

Top-level value

Any JSON value since RFC 7159 — 42, "text" and null are all valid documents, not only objects and arrays

Default encoding

UTF-8. The application/json media type defines no charset parameter, so a charset= on the Content-Type is ignored

Duplicate names

RFC 8259 §4 says object names SHOULD be unique and leaves the rest undefined. JSON.parse keeps the last occurrence and silently discards earlier ones

Numbers

No leading +, no leading zeros (02 is invalid), no hex, and no Infinity or NaN. RFC 8259 §6 warns that IEEE 754 doubles lose precision beyond 2^53 − 1

Not valid JSON

Trailing commas, // and /* */ comments, single-quoted strings, and unquoted object keys — all common in hand-written config, all rejected

String escapes

\" \\ \/ \b \f \n \r \t and \uXXXX. Literal control characters below U+0020 must be escaped

Common mistakes to avoid

Treating JSON5, JSONC or a JavaScript object literal as JSON

Why it happens: Comments, trailing commas, single-quoted strings and unquoted keys are all legal in the config dialects that editors and bundlers accept, and none of them are legal JSON. RFC 8259 has no comment production at all. So a tsconfig.json that VS Code opens happily fails here with "Expected property name or '}' in JSON at position 1" the moment it contains // notes, and the same file will break any strict parser in a CI step.

How to avoid it: Decide which dialect a file really is and use a parser that matches. If a file must keep comments, name it .jsonc or .json5 and use a tolerant loader; if it must be strict JSON, move explanatory text into a "_comment" member or a sibling README. When you are handed a broken file, delete the comments and trailing commas here first, then format — the remaining errors are the real ones.

Assuming large integer IDs survive a round trip

Why it happens: JSON numbers have no defined size limit, but JSON.parse produces IEEE 754 doubles, which hold integers exactly only up to 2^53 − 1 (9007199254740991). A Twitter-style or Snowflake-style 64-bit ID such as 12345678901234567890 comes back as 12345678901234567000 — silently, with no error. RFC 8259 §6 explicitly warns that numbers outside that range risk losing interoperability.

How to avoid it: Transport large identifiers as strings: "id": "12345678901234567890". Round-tripping such a document through any JavaScript-based formatter, including this one, will rewrite the number, so treat a formatted copy as a reading aid rather than a source of truth. If you must keep numeric IDs, use a BigInt-aware parser on the server side and never let a JS tool re-serialise the payload.

Relying on duplicate keys to override an earlier value

Why it happens: RFC 8259 §4 says names within an object SHOULD be unique and declares behaviour undefined otherwise, so implementations genuinely disagree: JavaScript keeps the last occurrence, some parsers keep the first, some collect both into a list, and some raise an error. A document that works with one library quietly changes meaning with another, and formatting it here collapses the duplicates without warning you they existed.

How to avoid it: Never emit duplicate names. If you are merging documents, do the merge in code so the precedence rule is explicit and testable, then serialise once. When you suspect a payload has duplicates, compare the number of members before and after a round trip through this tool — a drop in key count is the tell.

Expecting key order or formatting to be semantically meaningful

Why it happens: RFC 8259 defines an object as an unordered collection of name/value pairs. Nothing about member order, whitespace, or indentation is part of the data, so a proxy, a database JSON column, or a language binding is free to reorder members. Signature and checksum schemes that hash a pretty-printed document break the first time anything in the chain re-serialises it.

How to avoid it: Treat formatting as presentation only. For diffs, normalise with Sort keys on both sides so order cannot cause noise. For signing or hashing, use a canonicalisation scheme with defined rules (such as JCS) rather than whatever your formatter emits, and sign the canonical bytes rather than the readable ones.

Converting deeply nested JSON to CSV and expecting the nesting to survive

Why it happens: CSV is a flat table of rows and columns, described by RFC 4180, with no concept of a nested record or a repeated field. When a value is an object or an array, there is no column that can hold it, so conversion either flattens it into an unreadable cell or drops the structure. The result looks like a successful export right up to the point someone tries to read a nested field.

How to avoid it: Flatten intentionally before converting: choose the record array you actually want as rows, and project the nested fields you need into top-level keys with names like meta_active. If the shape is genuinely hierarchical, convert to YAML or XML instead — both represent nesting natively — and keep CSV for the tabular slice a spreadsheet user actually asked for.

Frequently asked questions

How do I find the line causing a JSON parse error?

Paste the document and press Validate. Browsers report parse failures as a character offset, which is unusable in a single-line payload, so this tool converts the offset into a line and column and appends it: "Unexpected number in JSON at position 20 (line 3, col 9)". If the input is one long line, press Beautify on a repaired copy first so the reported line numbers become meaningful. Note that V8 blames the first character it could not accept, which is often one token after the real mistake — a trailing comma is reported at the closing brace on the following line.

Is pretty-printed JSON slower or larger in production?

Larger in raw bytes, but far less than the character count suggests. Indentation is highly repetitive, and both gzip and Brotli compress it very efficiently, so a pretty-printed response often costs only a few percent more over the wire than a minified one. Parse time is essentially unchanged. The usual advice still holds: minify machine-to-machine API responses because nothing reads them, and keep configuration and fixture files formatted because humans and diff tools do. Use Minify here to measure the real difference for your own payload rather than guessing.

Does JSON allow comments or trailing commas?

No. RFC 8259 defines no comment syntax and its grammar does not permit a comma before a closing brace or bracket. Douglas Crockford removed comments deliberately so they could not be abused to carry parsing directives. The dialects you may be thinking of are extensions: JSONC (used by VS Code settings and tsconfig.json) adds comments, and JSON5 adds comments, trailing commas, unquoted keys and single quotes. Both need a tolerant parser. This tool uses the browser's strict JSON.parse, so it will reject all of them and point at the offending character.

Should I indent JSON with 2 spaces or 4?

Two spaces is the de facto standard for JSON in JavaScript and web tooling: npm writes package.json with two, and JSON.stringify examples in the ECMAScript spec and on MDN use two. Four spaces is common where JSON sits alongside Python or Java code that already uses four. Tabs are valid JSON whitespace and are the right choice if your editor config or accessibility requirements call for them. What matters most is consistency inside a repository, because mixed indentation produces whitespace-only diffs. This tool offers 2, 3 and 4 spaces plus 1–4 tabs.

Why did my large ID number change after formatting?

Because JSON.parse converts every number to an IEEE 754 double, which represents integers exactly only up to 2^53 − 1, or 9007199254740991. An ID like 12345678901234567890 is rounded to the nearest representable double and re-emitted as 12345678901234567000. No error is raised, which is what makes it dangerous. RFC 8259 §6 warns about exactly this. The fix is on the producing side: send 64-bit identifiers as JSON strings. Any JavaScript-based formatter, in a browser or in Node, has the same limitation.

Can I convert JSON to CSV, YAML, XML or TOML here?

Yes — use the Convert to dropdown, which offers JSON, YAML, CSV, XML and TOML and re-renders as soon as you change it. YAML and TOML handle nesting natively. XML wraps the value in a single root element, and a top-level array becomes <root><item>…</item></root> so the document stays well-formed; keys that are not valid XML names have illegal characters replaced with underscores. CSV needs an array of flat objects, since a table has no column type that can hold a nested record. For heavier conversion work the dedicated JSON ↔ YAML, JSON ↔ CSV and TOML tools offer options this dropdown does not.

Is it safe to paste production JSON into an online formatter?

It depends entirely on whether the tool sends your data anywhere. This one does not: parsing, sorting, tree building and every format conversion run in your browser with JSON.parse and JSON.stringify, and no request carries the payload. That matters because API responses routinely contain bearer tokens, session identifiers, email addresses and internal hostnames. As a general habit, check whether a formatter works offline — load the page, disconnect, and see if it still formats — and prefer local tooling such as jq for anything covered by a data-handling policy.

References

• RFC 8259 — The JavaScript Object Notation (JSON) Data Interchange Format
• MDN — JSON.stringify()
• MDN — JSON.parse()
• ECMA-262 — Structured Data (JSON object)
• RFC 4180 — Common Format and MIME Type for CSV Files