JSON is the dominant data interchange format in modern software — it powers nearly every REST API, ships as the default for NoSQL document databases, serves as the configuration format for most build tools, and backs the message formats for every major event-streaming system. Despite that ubiquity, JSON trips up developers in specific predictable ways: strict syntax rules that differ from JavaScript object literals, implementation edge cases around large numbers and Unicode, and questions about when to minify versus pretty-print. The sections below cover what actually counts as valid JSON, the minify-vs-pretty-print decision, the five most common syntax errors, and practical tips for working with JSON in real-world workflows.

What Counts as Valid JSON?

JSON (RFC 8259) is stricter than most developers expect, and the strictness catches even experienced engineers on a regular basis. All strings must use double quotes — single quotes and unquoted keys are both syntax errors, even though they're both valid in JavaScript object literals. Trailing commas after the last element of an object or array are forbidden, unlike in modern JavaScript and Python where they're actively encouraged for diff-friendly source control. Comments of any kind are not allowed in valid JSON — neither `//` line comments nor `/* */` block comments appear anywhere in the specification. The root value must be an object, array, string, number, boolean, or null; top-level values outside these types (functions, dates, undefined) fail validation. Numbers follow a specific grammar that excludes `NaN`, `Infinity`, and `-Infinity` as literal values, and excludes leading zeros on integer parts (except for 0 itself). These rules differ from JavaScript object literals, which is why hand-written "JSON" often fails validation when pasted into this tool or into a programming language parser. The practical takeaway is to always validate generated JSON before committing it to version control, shipping it as an API response, or storing it in a database — a parse error three environments downstream is far more expensive to debug than one caught immediately in the formatter.

When to Minify vs Pretty Print

The minify-versus-pretty-print choice has a simple answer driven by audience: minify for machine consumption, pretty print for human consumption. Machine consumption covers API responses, database storage, message queues, log aggregation, network transmission, and any context where bytes matter and readability doesn't. A typical REST API response shrinks 25–40% after minification, which directly reduces bandwidth costs, lowers page-load latency, and frees database storage. Combined with gzip or brotli compression at the HTTP layer, the total savings can reach 80–90% for large payloads. Pretty print covers configuration files checked into version control, documentation examples, README snippets, debugging output, and anywhere a human will actually read the content. The indentation style choice (2 spaces, 4 spaces, or tabs) depends on the surrounding project conventions — use 2-space indent for most JavaScript, TypeScript, and web-ecosystem projects (the de facto standard), use 4-space for Python-adjacent workflows (matching PEP 8 conventions for Python itself), and use tabs for projects that enforce tab-only style (uncommon but still present in some Go and older Java codebases). This tool defaults to 2-space indent and remembers your preference across sessions. Sort Keys is a closely related option that makes JSON files deterministic — two logically equivalent objects produce byte-identical output, which matters for reliable diffs in version control and for caching.

Common JSON Errors

Five specific errors account for the overwhelming majority of JSON parse failures, and recognizing them at a glance saves significant debugging time. First, trailing commas: `{"a": 1, "b": 2,}` is invalid JSON despite being valid and preferred JavaScript. Remove the comma after the last value or click the Repair button. Second, single quotes: `{'key': 'value'}` is a Python dict serialization or JavaScript object literal, not JSON. All JSON strings require double quotes, and the Repair button replaces single quotes with double quotes while handling escaped characters correctly. Third, embedded comments: JSON has no comment syntax despite widespread use of JSONC ("JSON with Comments") in editor configuration files and build tool configs. JSONC is a VS Code extension, not a spec-compliant dialect. Strip comments before parsing, which Repair does automatically. Fourth, unquoted keys: `{name: "Alice"}` is valid JavaScript but not valid JSON — keys must be double-quoted strings. This one commonly slips in when copying from JavaScript source code. Fifth, NaN, Infinity, and -Infinity: the JSON specification only allows finite numbers, and these special floating-point values must be represented as strings ("NaN") or null values depending on the downstream application's needs. Many language parsers silently accept these as extensions but spec-compliant parsers reject them. The Validate button in this tool reports the exact line and column of the first error, which is typically enough to identify the problem instantly.

Practical Tips for Working with JSON

A handful of practical workflow tips cover most real-world JSON tasks. Use the Tree Explorer for large payloads — it renders lazily, so even 10 MB files stay responsive. Search by key name to jump directly to the data you need rather than scrolling through thousands of lines of formatted text. Sort keys before comparing two JSON objects: two logically equivalent objects with keys in different order look different in a text diff but become byte-identical after sort. Sort Keys produces deterministic output for reliable version-control diffs and cache-key generation. Export arrays of flat objects to CSV for spreadsheet work — if your JSON is a list of records where each record has the same keys, the CSV converter turns it into a table you can open directly in Excel or Google Sheets. Nested objects within rows are serialized as JSON strings in their cells, preserving structure without breaking CSV's flat-table assumptions. Try Repair before rejecting invalid JSON — it fixes the three most common issues (trailing commas, comments, single quotes) and saves time on manual line-by-line debugging. For very large files (50+ MB), consider streaming parsers like `jsonstream` (Node.js) or `ijson` (Python) rather than loading the entire file into memory; this browser tool handles up to about 50 MB comfortably before memory pressure becomes noticeable. For API debugging, use the browser's DevTools Network tab to copy response payloads into this tool for exploration, rather than parsing complex responses in the DevTools console.