JSON Formatter & Validator

What is JSON?

JSON (JavaScript Object Notation) is a lightweight text format for storing and exchanging data. It was derived from JavaScript object syntax but is now language-independent — virtually every programming language has a JSON library. A valid JSON document is either an object ({}), an array ([]), a string, a number, a boolean, or null.

JSON is the default data format for most REST APIs, configuration files (like package.json, tsconfig.json), and browser storage. Its readability and simplicity made it replace XML for most use cases in the 2000s, and it remains the dominant wire format for web services today.

Common JSON validation errors and how to fix them

The most frequent JSON errors come from a few predictable sources:

• Trailing commas — [1, 2, 3,] is invalid JSON (though valid in JavaScript). Remove the last comma before the closing bracket.
• Single quotes — JSON requires double quotes for strings and keys. {'key': 'value'} is a JavaScript object literal, not JSON. Swap all single quotes for double quotes.
• Unquoted keys — { key: 'value' } is not valid JSON. Keys must always be double-quoted strings: { "key": "value" }.
• Comments — JSON has no comment syntax. Inline // ... or block /* ... */ comments will cause a parse error. Use .jsonc (JSON with Comments) format for files that need them — but those can't be parsed by standard JSON.parse().
• Undefined and NaN — undefined, NaN, and Infinity are not valid JSON values. They exist in JavaScript but have no JSON equivalent; JSON.stringify() silently drops undefined properties and converts NaN/Infinity to null.

JSON vs YAML: when to use which

JSON and YAML represent similar data structures but have different strengths. JSON is strict, unambiguous, and universally supported — it's the right choice for APIs, wire protocols, and any programmatic data exchange. YAML is more human-friendly for configuration files: it supports comments, multiline strings without escape sequences, and a less cluttered syntax.

A practical rule: use JSON for data that code produces and consumes, use YAML for configuration files that humans edit. Most CI systems (GitHub Actions, Railway), container orchestration (Kubernetes, Docker Compose), and IaC tools (Ansible, Helm) use YAML for this reason. When in doubt, JSON's strictness is an advantage — YAML has several sharp edges (boolean parsing, octal numbers, the "Norway problem") that can cause subtle bugs.

JSON in REST APIs: best practices

When building JSON APIs, a few conventions reduce friction for consumers: use camelCase for field names (consistent with JavaScript conventions), include a top-level data key for the payload and error for errors rather than mixing them, and always return arrays rather than objects when a list is expected — even if the list is empty. This prevents clients from having to handle both { items: [...] } and { items: null }.

For large responses, consider pagination with cursor or offset+limit fields. Document your schema with OpenAPI/Swagger so consumers can validate against it. And always set Content-Type: application/jsonon responses — some clients behave unexpectedly when it's missing.