Tool Magic Lab

JSON Formatting and Validation Guide: Read It, Fix It, Trust It

Developer Β· Published 2026-10-28 Β· Updated 2026-11-15 Β· 8 min read Β· By Tool Magic Lab Editorial Team

Illustration of a JSON document with braces and key-value pairs being formatted into clean indented lines

JSON won. APIs, config files, logs, data exports β€” the curly-brace format is the default language of systems talking to systems. It is also, in the wild, frequently a single 40 KB line with an error somewhere inside it. This guide covers how JSON actually works, the handful of mistakes behind almost every failure, and a reliable workflow for making any blob readable and provably valid.

JSON in one minute

JSON (ECMA-404) has six building blocks: objects (unordered key–value pairs in braces), arrays (ordered lists in brackets), strings (double-quoted, with backslash escapes), numbers, booleans and null. Keys must be strings. There are no comments, no trailing commas, no single quotes, no dates β€” dates travel as strings, which is why every API invents its own convention and every developer has been bitten by one. That is the entire grammar; everything else is discipline.

The five errors behind nearly every failure

A validator that reports the position of the first error turns all five from mysteries into ten-second fixes: the JSON Validator (/developer/json-validator) does exactly that, and the JSON Formatter (/developer/json-formatter) then indents the corrected document so a human can actually review it.

Formatting is a debugging tool

Indentation is not cosmetics. A formatted document lets you collapse levels, compare two payloads structurally, and spot the field that is a string where a number should be β€” the class of bug that passes validation (it is valid JSON) while breaking your code (it is the wrong shape). For comparisons, sort keys if your tooling allows it, then diff: structural sameness becomes visible immediately. Minified JSON still has its place β€” in transit, where bytes cost money β€” but humans should never have to read it.

Validation vs schema: know which you need

Syntactic validation asks 'is this JSON?' Schema validation asks 'is this the JSON we agreed?' β€” required fields present, types correct, values in range. The first is a parser's job; the second is a contract's job (JSON Schema is the standard vocabulary). Most 'the API broke' incidents are schema breaks wearing a syntax costume: valid JSON, wrong content. Tools like our Schema Generator and Schema Validator help on the structured-data side for web pages; for APIs, encode the contract in a schema file in your repo and test against it in CI.

Converting JSON without lying to yourself

JSON converts to CSV (when the data is genuinely flat β€” nested objects force choices about flattening that must be made consciously), to XML (with attribute-versus-element decisions), and to YAML (a superset in spirit, so the trip is usually safe). The JSON to CSV, JSON to XML and YAML tools on Tool Magic Lab show the output before you download it, because every conversion embeds decisions; a converter that hides them is making them for you, silently.

Frequently asked questions

**Why does the parser's error line never match the real mistake?** Parsers report where parsing became impossible, which is downstream of the actual defect β€” usually an unclosed string or bracket earlier. Format what you can, then hunt backwards from the reported position.

**Is JSON case-sensitive?** Keys are ordinary strings, so yes β€” 'Name' and 'name' are different fields, and true/false/null must be lowercase.

**How big can JSON be?** No spec limit; practical limits are memory and patience. Multi-megabyte payloads belong in files and streaming parsers, not browser tabs.

Written by the Tool Magic Lab Editorial Team. Tool Magic Lab content is produced with AI assistance and editorially reviewed for accuracy β€” see our AI Usage Disclosure and Editorial Policy.

#json#formatting#validation

Related articles