How to Format, Validate, and Minify JSON Online

You're staring at a 400 error. The API call looks right. The endpoint is correct. The headers are fine. Then you paste the request body into a formatter and see it immediately: a trailing comma after the last item in an array.

One character. Thirty minutes.

What Makes JSON Valid?

JSON has a small number of rules, but they're strict. The parser doesn't guess at intent — it either parses or it fails.

The three mistakes that cause most JSON errors:

Trailing commas — JSON does not allow a comma after the last element in an object or array. JavaScript does (since ES5). This difference trips up developers constantly when moving data between environments.

// Invalid
{
  "name": "Alice",
  "role": "admin",
}

// Valid
{
  "name": "Alice",
  "role": "admin"
}

Unquoted keys — JavaScript object literals allow unquoted keys ({ name: "Alice" }). JSON does not. Every key must be a double-quoted string.

Single quotes — JSON requires double quotes for both keys and string values. Single quotes are valid JavaScript but will fail JSON parsing every time.

// Invalid
{ 'name': 'Alice' }

// Valid
{ "name": "Alice" }

Formatted vs. Minified — When to Use Each

Both are valid JSON. The difference is whitespace.

Formatted JSON (also called pretty-printed) uses indentation and line breaks to make the structure readable. Use this during development, debugging, and code review. When a human needs to read it, format it.

Minified JSON strips all unnecessary whitespace to reduce file size and transmission time. Use this in production payloads, API responses, and anywhere bytes matter. A large formatted JSON file can be 20–30% larger than its minified equivalent.

The workflow: write and debug with formatted JSON, minify for production.

How to Format It in Seconds

The JSON Formatter on this site does three things: formats, validates, and minifies. Paste in any JSON — even broken JSON — and it immediately tells you whether it's valid and shows the first error if it isn't.

The validator is the most useful part for debugging. Instead of reading through a wall of minified JSON to find the problem, paste it in, click Format, and the error message tells you exactly which line and character failed.

For key naming conventions in your JSON — camelCase vs. snake_case vs. kebab-case — the Case Converter can help if you're normalizing key names across different data sources.

Five JSON Hygiene Rules

Keep these in mind when writing or reviewing JSON by hand:

• No trailing commas. Every item except the last one gets a comma.
• Double quotes only. On keys and string values, always.
• null, not NULL or Null. JSON is case-sensitive. So are true and false.
• Numbers don't need quotes. "age": 30 is correct. "age": "30" stores a string.
• Validate before you ship. One pass through a formatter catches errors a code review misses.

A Note on Sensitive Data in JSON

When pasting JSON into any online tool — including formatters — check that it doesn't contain API keys, tokens, or passwords. The Password Generator on this site generates cryptographically random secrets entirely in the browser, with nothing sent to a server. The same privacy-first approach applies to the JSON Formatter: your data never leaves your machine.

JSON in APIs: Practical Patterns

Most JSON in the real world is API data — either a request body you're sending or a response body you're parsing. A few structural patterns come up constantly:

Consistent key naming — An API with some keys in camelCase and others in snake_case is harder to work with than one that uses a single convention. When building an API, pick one and use it everywhere. When consuming one that mixes conventions, normalize at the parsing layer. The Case Converter handles bulk key renaming if you're cleaning up a dataset.

Null vs. missing fields — A key present with a null value means "this field exists but has no value." A missing key means "this field was not included." These are different states and APIs should use them consistently. Treating missing fields as null (or vice versa) causes subtle bugs in consumers.

Timestamps — ISO 8601 format ("2026-05-08T14:30:00Z") is the universal standard. Avoid Unix timestamps in JSON — they are ambiguous (seconds vs milliseconds), hard to read, and require conversion everywhere. Store dates as ISO strings and parse them on the consuming side.

Nested vs. flat structure — Deeply nested JSON is harder to navigate and document. A response with three levels of nesting is usually a sign that the API model is trying to do too much in a single call. Flatter is generally better.

Pagination — For any endpoint returning a list of items, include pagination metadata in the response: total, page, perPage, and a nextUrl or cursor. This is not part of JSON itself, but it is a convention so universal that omitting it causes problems immediately.

JSONC and YAML: When to Use Each

Standard JSON has no comment syntax. That is intentional — JSON is a data interchange format, not a configuration format. But configuration files are where many developers first encounter JSON, and configuration often needs comments.

JSONC (JSON with Comments) adds // and /* */ comment support to JSON. Used by VS Code's settings.json, TypeScript's tsconfig.json, and several other developer tools. If you are writing a configuration file in a tool that supports JSONC, use it — comments make intent clear without breaking parsers that support the format.

YAML is a superset of JSON that uses indentation instead of brackets, supports native comments, and is more readable for humans. Used heavily in CI/CD configurations (GitHub Actions, Docker Compose, Kubernetes). The tradeoff: YAML indentation errors are silent and hard to debug. The famous "YAML: YAML Ain't Markup Language" spec is more complex than it looks.

For most API payloads and data interchange: standard JSON. For developer configuration files where readability matters: JSONC or YAML depending on tool support. For machine-to-machine communication where size matters: consider MessagePack or Protocol Buffers — binary formats that are faster and smaller than JSON at scale.

When JSON Isn't the Right Tool

JSON is the right default for most data interchange. But it has limits:

• Comments aren't supported. If you need annotated configuration, JSONC (JSON with Comments) or YAML may be better choices.
• Large numbers lose precision. JSON numbers are IEEE 754 floats, which can't represent integers larger than 2^53 exactly. For large IDs or financial data, use strings.
• No schema enforcement. JSON itself doesn't validate types or required fields. For that, look at JSON Schema or a typed serialization format like Protocol Buffers.

For the vast majority of API work and configuration files, standard JSON is exactly right.

Quick Checklist

• [ ] All keys are double-quoted strings
• [ ] No trailing commas after the last item in any object or array
• [ ] All string values use double quotes (not single)
• [ ] true, false, and null are lowercase
• [ ] Ran the JSON through a validator before using it in production
• [ ] Minified the payload if it's being sent over a network