JSON Formatter & Minifier

JSON Formatter - Format and Validate JSON Online

A powerful online JSON formatter and validator tool that helps you format, beautify, minify, and validate JSON data. Features syntax highlighting, error detection with precise location, and various formatting options. Perfect for developers, API testers, and anyone working with JSON data.

How does the formatter handle invalid JSON?

The formatter runs your input through a strict JSON.parse pass first. If parsing fails, it shows the error message plus the line and column of the offending character (resolved in every major browser, including Firefox and Safari, not just Chrome), which points you at the likely cause: a trailing comma, single quotes instead of double, an unquoted key, a comment block, or an unterminated string. It never silently "fixes" your JSON, because that would mask real bugs in upstream producers. This tool validates strict JSON only — it does not parse relaxed dialects such as JSON5 or JSONC (comments, trailing commas, unquoted keys); strip those features before validating, since their output is no longer ECMA-404 JSON and may be rejected by downstream consumers. The strict parser conforms to RFC 8259 and ECMA-404, the two equivalent standards that define JSON.

What is the difference between JSON, JSON5, JSONC, and NDJSON?

JSON (RFC 8259 / ECMA-404) is the strict canonical format: double-quoted keys, no comments, no trailing commas. JSONC ("JSON with comments") is the VS Code variant that allows // and /* */ comments; it is used for tsconfig.json and settings files. JSON5 is a richer superset that adds unquoted ECMAScript-identifier keys, single quotes, multi-line strings, hex numbers, leading/trailing decimal points, +Infinity, NaN, and trailing commas. NDJSON (newline-delimited JSON) is a streaming format where each line is a complete JSON value, used for log files, machine-learning datasets, and API streams. They are NOT interchangeable: a strict JSON parser will reject JSONC and JSON5; an NDJSON file is not a single valid JSON document. Pick based on consumer: APIs almost always require strict JSON.

Why does my JSON suddenly contain numbers like 9999999999999999 turning into 10000000000000000?

JSON itself imposes no limit on numeric precision, but most parsers — including JavaScript's JSON.parse — store numbers as IEEE 754 double-precision floats, which can exactly represent integers only up to 2^53 - 1 (about 9.007 quadrillion, or Number.MAX_SAFE_INTEGER). Larger integers silently round to the nearest representable double. This bites APIs that return 64-bit IDs (Twitter, Discord snowflakes, database BIGINT primary keys) — by the time JavaScript parses them, the last few digits are wrong. Fixes: (1) the server should serialize large integers as strings; (2) use a BigInt-aware parser like json-bigint or the reviver parameter of JSON.parse to intercept the raw token; (3) parse manually as a string. Floats have the analogous issue with decimal fractions — 0.1 + 0.2 = 0.30000000000000004.

Should I minify JSON for production APIs?

Yes for size-sensitive endpoints, no for everything else. Minifying strips all whitespace (spaces, tabs, newlines around : and ,) and typically saves 20-40% of bytes depending on key length and value distribution. The wire savings are largely erased once HTTP gzip or Brotli compression kicks in — modern compressors handle whitespace efficiently — so the practical gain over compressed transport is often under 5%. The trade-off: minified JSON is unreadable in browser DevTools and log aggregators, making production debugging harder. Best practice: serve pretty-printed JSON in development and on internal APIs, minified JSON only for public high-traffic endpoints where every byte matters and consumers are machines. Configure Content-Encoding: gzip or br at the server level — this gives most of the benefit with none of the readability cost.

Why does the formatter sort my keys, and can I turn it off?

Key sorting is optional and off by default in this tool — formatting preserves the original key order from your input. Some workflows benefit from sorted keys: deterministic output for git diffs, canonical JSON for cryptographic signing (JCS, RFC 8785), and reduced merge conflicts. Other workflows depend on insertion order: OpenAPI schemas where required fields are listed first, log records where timestamp must come first, configuration files following a documented template. JavaScript objects preserve insertion order for string keys per ES2015, and JSON.stringify reflects that order; JSON.parse also preserves order on round trip. If you do want sorted output, this tool's "Sort keys" option performs a deep recursive sort using locale-aware comparison; numeric string keys are sorted as numbers when appropriate.

How do I find a specific value or path inside a large JSON file?

For ad-hoc exploration, JSONPath ($..book[?(@.price<10)]) and JMESPath (locations[*].name | sort(@)) are query languages designed exactly for this — both have JavaScript implementations. The jq command-line tool is the most powerful option for shell pipelines: jq '.users[] | select(.age > 30) | .name' filters and projects in one expression. For tree navigation in this formatter, use the collapsible nodes to drill in visually, then use Ctrl+F to text-search. For truly massive files (above 100 MB), avoid loading the whole document into memory — use streaming parsers like Node.js stream-json, Python ijson, or Go encoding/json's Decoder to process tokens one at a time. Indexing into a database (SQLite JSON1, Postgres JSONB) is the right answer once a file is queried repeatedly.

Why does my parser reject duplicate keys in an object?

RFC 8259 says the behavior is implementation-defined: "The names within an object SHOULD be unique." Most parsers do not raise an error; they silently keep the last value seen (JavaScript JSON.parse), or the first (some Go libraries with custom unmarshalers), or merge them (rare). This ambiguity is a real source of bugs and security issues — see JSON Interoperability Vulnerabilities (CVE patterns in HTTP smuggling and JWT verification). The safest practice is to surface duplicates: this tool scans the raw text and warns you whenever a key repeats inside the same object, naming the key and the line/column of the SECOND occurrence (the value JSON.parse silently kept) so you can fix the producer. The warning appears on Validate, Format, and Minify and never blocks the operation. If you must tolerate duplicates for historical reasons, document which value wins and unit-test it. JCS (RFC 8785, canonical JSON for signing) outright forbids duplicate keys.

How does the built-in JSONPath query work?

Type a JSONPath expression in the Query field and click Run Query to extract matching values without external tools. The evaluator supports $ for the root, .field and ['field'] for properties, [0] and [-1] for array indices, [*] for every child, ..field for recursive descent at any depth, ['a','b'] unions, and filter predicates like [?(@.price<10)] or [?(@.active==true)] with the operators == != < <= > >=. Examples: $.store.book[*].author returns every author; $..price collects every price anywhere in the document; $.users[?(@.age>30)].name returns the names of users over 30. Results are returned as a JSON array and the status bar shows the match count; an empty array means nothing matched. This runs entirely in your browser, so it is safe for sensitive payloads, and it pairs well with the collapsible tree for locating a path before querying it.

How do I escape special characters like newline, tab, or quote inside a JSON string?

JSON strings use a small set of backslash escapes defined in RFC 8259 section 7: \" for double quote, \\ for backslash, \/ for forward slash (optional), \b for backspace, \f for form feed, \n for newline, \r for carriage return, \t for tab, and \uXXXX for any Unicode code point up to U+FFFF. Code points above U+FFFF (emoji, rare CJK) use a UTF-16 surrogate pair: \uD83D\uDE00 for 😀. Control characters U+0000 through U+001F MUST be escaped — a literal newline byte inside a JSON string is invalid. Forward slash escaping is permitted but not required; many tools escape it inside </script> to defend against HTML injection when the JSON is embedded in <script> tags. This formatter preserves your escape style on round trip and offers a normalize option.

Key Features

• Format JSON with customizable indentation (2, 4, 8 spaces, or tabs)
• Minify JSON to reduce file size for production
• Validate JSON syntax with precise error location
• Syntax highlighting for better readability
• Sort object keys alphabetically
• Real-time statistics (characters, lines, size)
• Copy formatted JSON to clipboard
• Download formatted JSON as .json file
• Upload JSON files for formatting
• Dark mode support
• No file size limits
• 100% client-side processing - your data never leaves your browser
• Works offline after initial load
• Mobile-friendly responsive design