JSON Formatter

Why JSON formatting matters beyond aesthetics

Formatted JSON is not just easier to read — it is significantly easier to diff, debug, and review in code. When you paste minified JSON into a git diff or a code review, reviewers must parse a single dense line mentally. A formatted version lets git show you exactly which key changed on which line.

Formatting also reveals structural problems that are invisible in minified output. An extra closing brace, a misplaced comma, or a null where an object is expected jumps out immediately in indented form. Many developers format JSON as the first debugging step before trying to understand an unexpected API response.

The formatter also validates your JSON against RFC 8259, which has stricter rules than many developers expect. Common mistakes: trailing commas after the last key in an object (valid in JavaScript but not JSON), single-quoted strings (JSON requires double quotes), and unquoted keys (also only valid in JavaScript). If a service produces JSON with these patterns, it is technically broken — even if JavaScript can eval() it.

Strict JSON vs JSONC and JSON5 — the variants explained

Standard JSON (RFC 8259) has no comments and strict syntax. This is intentional — Douglas Crockford, who specified JSON, explicitly rejected comments to prevent people from using them as parsing directives (the way XML does with processing instructions), which would undermine JSON's simplicity.

JSON with Comments (JSONC) extends JSON to allow // line comments and /* block comments */. It is used by VS Code for its settings.json and tsconfig.json files. JSONC files are not valid JSON and cannot be parsed by a standard JSON parser — they require a JSONC-aware parser.

JSON5 is a more permissive superset that additionally allows trailing commas, single-quoted strings, multi-line strings, hexadecimal numbers, and leading/trailing decimal points. It is used by some configuration tools but is not widely adopted in APIs.

This formatter validates against strict RFC 8259 JSON. If you need to parse JSONC or JSON5, strip comments first with a preprocessing step before using a standard parser.

When to minify JSON and when not to

Minified JSON strips all whitespace (spaces, newlines, indentation) to produce the most compact representation. The right time to minify is when JSON is being transmitted over a network — in API responses, embedded JavaScript bundles, or stored in a database where storage cost matters.

For API responses, minification typically reduces JSON size by 20–40%. Combined with gzip or Brotli compression at the HTTP layer, the additional savings from minification are smaller (gzip already handles repeated whitespace efficiently), but minification still reduces the raw byte count before compression.

Do not minify JSON that humans will read and edit directly: configuration files, seed data, test fixtures, and documentation examples should stay formatted. The cognitive cost of manually reading minified JSON far outweighs the byte savings. A good rule: minify for machines, format for humans.

JSON naming conventions — camelCase, snake_case, and API design

There is no official JSON naming convention — the format specifies that keys are Unicode strings, nothing more. In practice, conventions follow the language ecosystem that produces or consumes the JSON.

JavaScript-native APIs (GitHub, Stripe, Twitter/X) use camelCase keys (createdAt, userId, firstName) because JavaScript developers can destructure them directly into variables without renaming. Python-native APIs (SendGrid, many Django-based services) use snake_case (created_at, user_id, first_name) because snake_case is PEP 8's Python convention.

REST API design guides generally recommend choosing one convention and applying it consistently across all endpoints, request bodies, and response fields. Mixing conventions in the same API — camelCase for some endpoints and snake_case for others — is a common source of client-side bugs.

For pagination, most modern APIs use one of two patterns: offset/limit ({"offset": 0, "limit": 20, "total": 142}) or cursor-based ({"next_cursor": "eyJpZCI6MTIzfQ", "has_more": true}). For errors, the RFC 7807 "Problem Details" format ({"type": "...", "title": "...", "status": 400, "detail": "..."}) is an emerging standard worth following for machine-readable error responses.

JSON Schema — validating structure, not just syntax

A syntactically valid JSON document might still be semantically wrong for your application: a required field missing, a string where a number is expected, or an array containing the wrong object shape. JSON Schema is a vocabulary for describing the expected structure of a JSON document and validating inputs against that structure.

A basic JSON Schema for a user object specifies required properties, their types, and any constraints: {"type": "object", "required": ["id", "email"], "properties": {"id": {"type": "integer"}, "email": {"type": "string", "format": "email"}, "age": {"type": "integer", "minimum": 0}}}. Validators like ajv (JavaScript) or jsonschema (Python) evaluate an input document against a schema and return detailed errors for each violation.

JSON Schema is foundational to OpenAPI (formerly Swagger), which uses it to define request and response body shapes for REST APIs. If you document your API in OpenAPI, your JSON Schema definitions become the single source of truth for validation, documentation, and client code generation. Pasting a JSON response into this formatter is often the first step before writing the schema that describes it.