JSON 101: How to Format, Validate, and Convert It Without the Headaches

5 min read

JSON looks simple. It's just curly braces, quotes, and colons — how hard can it be? Then you paste a 400-line API response into your editor, it's all on one line, and somewhere in there is a syntax error your build tool refuses to describe helpfully. This guide covers the parts of working with JSON that actually trip people up, and the fastest way through each one.

What JSON actually is (and isn't)

JSON — JavaScript Object Notation — is a text format for representing structured data: objects (key-value pairs), arrays, strings, numbers, booleans, and null. It was derived from JavaScript's object literal syntax, but it's stricter. That gap between "looks like a JS object" and "is valid JSON" is where most formatting errors come from.

A JSON object showing string, number, boolean, null, array, and nested object values, each labeled by type

The rules that trip people up most:

  • No trailing commas. {"a": 1, "b": 2,} is invalid — that last comma before the closing brace breaks it, even though it's completely fine in a JavaScript object literal.
  • Keys must be double-quoted strings. {a: 1} is invalid JavaScript-object-turned-JSON; it has to be {"a": 1}.
  • No single quotes. {'a': 1} fails. JSON strings are always double-quoted.
  • No comments. JSON has no comment syntax at all — not //, not /* */. If you need comments, you're probably looking for JSON5 or a different format like YAML.

Formatting vs. validating vs. minifying — these are different jobs

People often use "format" to mean all three of these, but they're distinct operations:

  • Formatting (beautifying) adds indentation and line breaks so a human can read the structure at a glance.
  • Validating checks whether the JSON is syntactically correct — no missing braces, no trailing commas, properly quoted strings.
  • Minifying strips all unnecessary whitespace to make the payload as small as possible for network transfer.

A good JSON Formatter does the first two at once: it parses your input (which validates it) and then re-serializes it with your chosen indentation (which formats it). If parsing fails, you get a specific error instead of garbage output — that's the real value over just eyeballing the raw text.

The fastest way to find a JSON syntax error

Staring at 200 lines of minified JSON looking for a missing comma is slow and error-prone. Here's the actual efficient process:

  1. Paste it into a formatter first, even if it's broken. A good formatter will still tell you where it failed, which narrows your search from "somewhere in this file" to "line 47."
  2. Check the character right at the reported position, not just the line. JSON parsers often report the position where they noticed the problem, which is sometimes a few characters after where the actual mistake is (a missing comma is detected when the parser hits the next token, not where the comma should have been).
  3. Common culprits, in order of likelihood: trailing comma, a string that isn't properly escaped (an unescaped " inside a string value), a missing closing brace or bracket, or a stray comment someone left in (JSON has none).

If you're debugging JSON regularly — say, inspecting API responses — a JSON Viewer that renders the structure as a collapsible tree is often faster than reading raw formatted text, especially for deeply nested objects where matching braces visually gets hard past a few levels.

When you need to compare two JSON objects

Diffing JSON by eye is where mistakes hide longest — a single changed value three levels deep in a large object is nearly invisible in a side-by-side text comparison. This is common when comparing two versions of a config file, or checking whether an API response changed between two environments. A dedicated JSON Compare tool that walks both objects and reports exactly which keys were added, removed, or changed — with the full path to each difference — turns a five-minute manual scan into a two-second glance.

Converting JSON to other formats

JSON isn't always the right format for the destination. A few conversions come up often enough to be worth knowing:

  • JSON to YAML: YAML is more human-readable for configuration files (no braces, no quotes required on most strings) and is the standard for tools like Kubernetes, Docker Compose, and many CI pipelines. A JSON to YAML converter handles this instantly rather than hand-rewriting the structure.
  • CSV to JSON and back: spreadsheets and database exports are usually CSV; APIs and modern applications usually want JSON. Converting between them is common enough to be worth a dedicated tool rather than a script you rewrite every time.
  • JSON to a Schema: if you're documenting an API or want to validate future JSON against a known shape, a JSON Schema Generator can infer a starting schema from a real example, which is faster than writing one from scratch.

A quick mental model for avoiding JSON headaches

The single habit that prevents most JSON pain: format and validate before you commit, not after something breaks. If you're hand-editing a config file, run it through a formatter and validator before saving. If you're building a JSON payload programmatically, use your language's actual JSON serializer (JSON.stringify in JavaScript, json.dumps in Python) rather than string-concatenating it by hand — nearly all "invalid JSON" bugs in production code come from someone building JSON as a string instead of building a data structure and serializing it properly.

Frequently asked questions

Why does my JSON look fine but still fail to parse?

The most common invisible culprits are a trailing comma after the last item in an object or array, and smart quotes (curly quotes like “ ”) that got auto-substituted by a word processor instead of straight double quotes. Both look correct at a glance but fail strict JSON parsing.

Is JSON.parse() the same as a JSON validator?

Functionally, yes — JSON.parse() in JavaScript will throw an error on invalid JSON, which is exactly what most online JSON validators use under the hood. The main value a dedicated validator adds is a clearer error message and formatted output on success, rather than just a pass/fail.

Should I use JSON or YAML for my config file?

YAML is generally more pleasant to hand-write and read (no braces, minimal quoting, supports comments), which is why most infrastructure tools default to it. JSON is faster to parse, has no ambiguity in whitespace handling, and is the universal format for APIs. If humans will be editing the file directly, lean YAML; if it's machine-generated and machine-consumed, JSON is simpler.

Can JSON have comments?

No — standard JSON has no comment syntax at all. Some tools support JSON5 or JSONC (JSON with Comments) as extensions, but if you paste a JSON file with // or /* */ comments into a strict JSON parser, it will fail. If you need comments, YAML or a JSON superset like JSON5 is the better fit.

Related tools