The problem: your JavaScript runs fine but the API rejects it
You wrote an object literal in JavaScript, it works in your code, and you paste it into a config file or API request body and get a 400 error. The reason is that JSON is not JavaScript. It looks like JavaScript object syntax, which is the trap — it's a strict subset designed for data interchange, not for code. Every JSON document is valid JavaScript (you can paste it into a .js file and it parses), but most JavaScript object literals are not valid JSON. The formatter catches the difference, and the difference is six rules.
Fastest path
Paste your JSON into the JSON Formatter. If it's valid, you get formatted output with indentation, a tree view, and stats (key count, depth, type breakdown). If it's invalid, you get the error message and the line number. Fix the error, re-validate, and you're done.
If your input is a JavaScript object literal or a JSON5 file with comments and trailing commas, toggle the JSON5 mode. The tool strips comments, removes trailing commas, quotes unquoted keys, and converts single quotes to double quotes before validating.
The six rules that make JSON not JavaScript
1. Double quotes only
JSON requires double quotes around all strings and all property names. Single quotes are not allowed.
// Invalid — single quotes
{'name': 'Alice', 'age': 30}
// Valid
{"name": "Alice", "age": 30}
JavaScript accepts both. JSON accepts one. This is the most common validation failure, and the fix is mechanical: replace every ' with ".
2. No trailing commas
JSON forbids a comma after the last item in an object or array. JavaScript allows it (and browsers ignore it), which is why people paste JS objects that work in the console but fail JSON validation.
// Invalid — trailing comma after "age"
{"name": "Alice", "age": 30,}
// Valid
{"name": "Alice", "age": 30}
3. Quoted property names
In JavaScript, you can write {name: "Alice"} without quoting the key. In JSON, the key must be a double-quoted string: {"name": "Alice"}. Numbers as keys are also invalid — {"0": "first"} is fine, {0: "first"} is not.
4. No comments
JSON does not support comments. Not // line comments, not /* */ block comments. This is intentional — Douglas Crockford designed JSON to be data, not code, and comments in data lead to programs that rely on comment-based configuration (which is fragile). If you need comments in your JSON, you're using the wrong format. Use YAML, TOML, or JSON5 (the tool handles JSON5 as an input format and strips comments before validating).
5. No undefined, NaN, or Infinity
JSON has seven value types: object, array, string, number, boolean, null. That's it. undefined is not valid JSON. NaN and Infinity are not valid JSON numbers — despite being JavaScript number values, the JSON spec (RFC 8259) says numbers are decimal literals, and NaN/Infinity are identifiers, not number literals. JSON.stringify({value: NaN}) produces {"value":null} in JavaScript, silently converting NaN to null. If your API sends NaN, the JSON serializer drops it.
6. Only one top-level value
A JSON document is exactly one value. {"a": 1}{"b": 2} is two values and is invalid — a parser stops after the first }. If you have a stream of JSON objects, they need to be in an array ([{"a": 1}, {"b": 2}]) or separated by newlines as JSONL (JSON Lines), which is a different format that the tool doesn't parse as standard JSON.
Format vs minify: the two modes and when to use each
Formatting (pretty-printing, beautifying) adds line breaks and indentation so the structure is visible. Use it when debugging, reviewing API responses, editing config files, or sharing JSON with another person. The tool's default is 2-space indentation, which is the convention in most web projects. 4-space is common in Java and .NET ecosystems. Tab indentation exists but is rare in JSON because tabs render inconsistently across editors.
Minifying strips all whitespace — every space, newline, and indentation character — producing the smallest valid string. Use it when sending JSON over the network or storing it where size matters. A formatted JSON file with 10,000 lines might minify to a single 200 KB line. The data is identical; only the whitespace changes. JSON.parse produces the same object from both.
The workflow: format while developing, minify for production. The tool does both with one click each way.
The JSON5 escape hatch
JSON5 is a superset of JSON that adds JavaScript conveniences: comments, trailing commas, unquoted keys, single-quoted strings, hexadecimal numbers, and Infinity/NaN as values. It's not part of the JSON spec, but it's common in configuration files (VS Code's jsconfig.json, Babel configs, some webpack configs).
The tool's JSON5 mode converts JSON5 to standard JSON before validating. It strips // and /* */ comments, removes trailing commas before ] and }, quotes unquoted keys, and replaces single quotes with double quotes. The conversion is heuristic — it handles the common cases but can fail on edge cases like single-quoted strings containing escaped quotes. For JSON5 that's used as a config format, it's reliable. For adversarial input, it's not a parser.
Beyond formatting: schema and TypeScript generation
The tool does three things most formatters don't, and they're worth knowing about because they turn a formatting tool into a development workflow:
Schema generation. Paste an API response, and the tool generates a JSON Schema (draft-07) describing its structure — types, required fields, nested objects. This is the starting point for validating API responses in code. The schema is inferred from one sample, so it captures what the sample has, not what the API can return. A field that's null in the sample might be a string in other responses, and the schema will mark it as nullable (omitted from required). Use the generated schema as a draft, then refine it based on the API documentation. For the full schema workflow, the JSON Schema Generator is the dedicated tool with more options.
TypeScript generation. Paste a JSON sample, get TypeScript interfaces. The tool infers types recursively: objects become interface declarations, arrays of objects become ItemName[], nullable fields become optional (key?: type). This saves the manual work of typing out interfaces for API responses you're integrating with. The same caveat applies — one sample doesn't capture every possible shape. If the API sometimes returns a string and sometimes an array for the same field, the tool sees only the one in your sample.
Diff. Paste two JSON documents and the tool shows which keys were added, removed, or changed between them. This is useful for debugging API version differences — hit the same endpoint on staging and production, diff the responses, and see exactly what changed. The diff is value-based, not text-based, so reformatted or reordered keys don't create false positives.
Gotchas
- Key order is not guaranteed. The JSON spec says objects are "unordered collections of name/value pairs." Two JSON documents with the same keys in different order are semantically identical. But if you're diffing or comparing them as strings, the order matters. The tool's sort-keys option alphabetizes keys in every object, which makes string comparison reliable. It doesn't change the meaning of the data.
- Numbers are not precise. JSON numbers are IEEE 754 doubles in most parsers, which means
0.1 + 0.2in JSON is0.30000000000000004when you parse it in JavaScript. If you're storing currency or scientific data, use strings and parse them with a decimal library in your application. JSON has no decimal type. - Duplicate keys are silently overwritten.
{"a": 1, "a": 2}is technically valid JSON (the spec says objects "should" have unique keys, not "must"), and most parsers keep the last value. The tool follows this behavior. If you're debugging a config that's not working, check for duplicate keys — they're easy to miss in a large file. - Large files slow down the tree view. The tree view renders every node as a DOM element, which is fine for 500 keys but sluggish at 50,000. For large API responses, use the formatted text view and search within it. The 2 MB JSON file you got from a debug endpoint will format in under a second but may freeze the tree for several seconds.
- JSON5 conversion is lossy. Stripping comments is irreversible — once you convert JSON5 to JSON, the comments are gone. If the comments contain important configuration notes, keep the JSON5 source and convert a copy.
Summary
- JSON is a strict subset of JavaScript, not the same thing. Six rules make valid JS fail JSON validation: double quotes only, no trailing commas, quoted keys, no comments, no undefined/NaN/Infinity, one top-level value.
- Format for debugging, minify for transport. The data is identical; only the whitespace changes.
- JSON5 mode strips comments, trailing commas, and single quotes — the common "almost JSON" fixes — before validating.
- Schema and TypeScript generation infer types from one sample, which is a starting point, not a complete spec. Use the JSON Formatter for the formatting and validation workflow, the JSON Schema Generator for the dedicated schema tool, and YAML to JSON when your source config is in YAML.