JSON Formatter and Validator

What a JSON formatter actually does

A JSON formatter takes raw JSON text and rewrites it with consistent indentation, line breaks, and spacing so a human can actually read it. Most JSON arrives minified from an API response, a log line, or a config file — everything squashed onto one line with no whitespace. Feed that into a formatter and you get the same data, structurally identical, just laid out with each key on its own line and nested objects indented under their parent.

Under the hood this is a parse-then-print operation. The tool parses the text into an in-memory structure (objects, arrays, strings, numbers, booleans, null), then serializes that structure back out using your chosen indentation. Because it goes through a real parse step, a formatter is also a validator by definition: if the text isn't valid JSON, it can't be turned into that structure, and you get an error instead of a false beautified output.

This tool runs the parse and format entirely in your browser using the JavaScript engine's built-in JSON handling. Nothing you paste is uploaded anywhere, which matters if you're formatting API keys, tokens, or customer data pulled from a support ticket.

Beautify, minify, and sort keys explained

Beautify (pretty-print) expands compact JSON into a readable, indented form. You typically choose 2-space, 4-space, or tab indentation. For example, {"id":1,"name":"Ada"} becomes a three-line block with id on its own line and name on the next, each indented one level under the opening brace.

Minify does the opposite: it strips every non-essential character — spaces after colons, spaces after commas, newlines — and produces the smallest valid representation of the same data. Minifying matters when JSON is going over the wire or into a database column, since every byte counts at scale even though a single request rarely notices the difference.

Sort keys reorders every object's keys alphabetically, recursively, without touching array order (array order is meaningful and always preserved). This is useful for diffing two JSON payloads that should be identical but were generated by different code paths — with unsorted keys, a diff tool flags every line as changed even when the actual data matches; sorted keys make the diff show only the real differences [3](https://converter.run/json-formatter).

Worked example: fixing a broken payload

Say you paste this from an API log: {"user":{"id":42,"active":true,"roles":["admin","editor"]},"createdAt":"2024-03-01T12:00:00Z"}. Beautified with 2-space indentation, this becomes a nested block: an outer object with "user" and "createdAt" keys, "user" itself expanding into id, active, and a roles array with each string on its own line.

Now suppose there's a typo: {"user":{"id":42,"active":true,}}. That trailing comma before the closing brace is invalid in strict JSON (unlike JavaScript object literals, JSON has no trailing commas). A good formatter reports something like "Unexpected token } at position 27" or points to the exact line and column, rather than a vague "invalid JSON" message [3](https://converter.run/json-formatter).

Another common break: single quotes instead of double quotes, e.g. {'name': 'Ada'}. JSON requires double quotes for both keys and string values — single quotes are valid JavaScript object syntax but not valid JSON, so a strict validator rejects them and the formatter should tell you exactly where the unexpected character sits.

Common JSON mistakes and what the errors mean

Trailing commas are the single most frequent JSON error, especially when copying from JavaScript source code where trailing commas are allowed. Look for a comma immediately before a } or ].

Unquoted or single-quoted keys are the second most common issue — JSON keys must be double-quoted strings, always, no exceptions. Comments are another trap: JSON has no comment syntax at all, so // or /* */ left over from a JS config file will break parsing immediately.

Mismatched brackets — an array opened with [ but closed with } — and unescaped control characters or literal newlines inside string values also cause failures. A backslash that isn't part of a valid escape sequence (\n, \t, \", \\, \uXXXX) is invalid too; a raw Windows file path like "C:\Users\ada" needs its backslashes doubled to "C:\\Users\\ada".

NaN, Infinity, and undefined are valid in JavaScript but not in JSON — numbers must be finite and undefined simply doesn't exist as a JSON value. If your data has these, replace them with null or a string before validating.

Where JSON formatting fits in a real workflow

Debugging API responses is the most common use: copy a response body from your browser's network tab, paste it in, and read the structure instead of scrolling through one massive line. This is far faster than squinting at DevTools' inline preview for deeply nested objects.

Cleaning up config files is another — package.json, tsconfig.json, and similar files get hand-edited often enough that indentation drifts; running them through a formatter with a fixed indent width keeps a repository's style consistent before a commit.

Minifying for storage or transport comes up when embedding JSON into a URL query parameter, a database TEXT column, or an environment variable, where shorter is strictly better and whitespace serves no purpose.

Sorting keys before comparing two versions of a payload — say, a webhook body from staging versus production — turns a noisy diff into a clean one, since alphabetical order gives both sides the exact same layout regardless of the order fields were added in the source code.

JSON data types, in plain terms

JSON supports exactly six types: object ({ }), array ([ ]), string (always double-quoted), number (integer or decimal, no leading zeros, optional exponent like 1.5e10), boolean (true or false, lowercase, unquoted), and null (also lowercase, unquoted).

Numbers in JSON have no distinction between integer and float the way some languages do — 42 and 42.0 are both just "number". There's also no native date type; dates are always represented as strings, typically ISO 8601 like "2024-03-01T12:00:00Z", and it's up to the consuming application to parse that string into a real date object.

Object keys must be strings, always double-quoted, and duplicate keys are technically allowed by the JSON spec but produce undefined behavior across parsers — some keep the first occurrence, some the last. If you see duplicate keys in a formatted document, treat it as a bug in whatever generated the file.

JSON vs JavaScript object literals

JSON was inspired by JavaScript object syntax but is stricter and is its own independent standard used by virtually every language. The differences that trip people up: JSON keys must always be double-quoted (JavaScript allows unquoted identifier-style keys), JSON has no trailing commas, JSON has no comments, and JSON string values must use double quotes, not single quotes or backticks.

JavaScript can also have function values, undefined, Symbol, and Date objects in a literal — none of these exist in JSON. When you call JSON.stringify() on a JavaScript object containing these, they're either dropped, converted (Date becomes an ISO string), or throw, depending on the type.

This distinction matters when you copy an object literal straight out of source code expecting it to validate as JSON — it usually won't until you add quotes to keys and strip trailing commas and comments.

Privacy and size limits

Formatting, validating, minifying, and sorting all happen locally in your browser's JavaScript engine — the JSON you paste is never transmitted to a server, logged, or stored. This matters for JSON containing API tokens, database dumps, or personal customer data that you shouldn't be pasting into a third-party server-side tool anyway [2](https://tryutilix.com/dev/json-formatter).

Because everything runs client-side, the practical size limit is your browser's memory and how large a text area or code editor can render smoothly, not a server-imposed cap. Very large payloads — tens of megabytes — will format correctly but may feel sluggish to scroll or edit; for genuinely huge files, consider a command-line tool like jq for the bulk processing and use the browser formatter for spot-checking smaller sections.

Frequently confused terms

Pretty-print and beautify are the same operation, just different names used by different tools — both mean adding indentation and line breaks. Minify and compact are likewise interchangeable.

Validate means confirming the text parses as syntactically correct JSON; it says nothing about whether the data matches a particular shape or business rule. For checking that specific fields exist with specific types, you'd need a JSON Schema validator, which is a separate, stricter tool from a general-purpose formatter.

Linting, in the JSON context, usually just means validation plus style checks like consistent indentation — JSON itself has no semantic linting the way JavaScript does, since there's no logic to analyze, only structure.