The JSON and XML mistakes that break parsers most often, how formatting exposes them, and when to use JSON, XML or YAML.
An API returns a response on a single 4,000-character line. Somewhere in it is the field you need, or the syntax error breaking your parser. Squinting at it is a waste of time a formatter reindents the whole thing in one paste and usually makes the problem obvious immediately. JSON Formatter → | XML Formatter → What Formatting Actually Does Beautifying adds the indentation and line breaks that make structure visible. Minifying strips them out. Neither changes the data — same content, different presentation. Beautify when debugging, reading an unfamiliar API response, reviewing a config file, or comparing two structures. Minify when shipping data over a network or embedding it in a page, where every byte of whitespace is bandwidth spent on nothing. The other half of the job is validation : confirming the document actually parses, and pointing at the line where it doesn't. JSON Mistakes That Break Parsers Five errors account for the large majority of invalid JSON: Trailing commas. Legal in JavaScript object literals, illegal in JSON. {"a": 1, "b": 2,} fails. Single quotes. JSON requires double quotes on both keys and string values. {'name': 'value'} is not JSON. Unquoted keys. {name: "value"} is a JavaScript object, not JSON. Every key must be a quoted string. Comments. JSON has no comment syntax. // and /* */ both break parsing — a frequent surprise in config files where comments would be genuinely useful. Unescaped characters in strings. Literal newlines, tabs, and unescaped double quotes inside string values are invalid. They need \n , \t , and \" . A formatter that validates will name the line and character where parsing failed, which turns a hunt into a fix. XML: Different Rules, Different Failures XML is stricter than HTML in ways that catch people out: Every tag closes. No implicit closing. <br> must be <br/> . HTML tolerance doesn't carry over. Case sensitivity. <Item> and <item> are different elements. One root element. An XML document has exactly one top-level element containing everything else. Five reserved characters. < , > , & , " , and ' must be escaped as < , > , & , " , and ' inside content. An unescaped ampersand — common in URLs inside XML — is one of the most frequent causes of a broken feed. Attribute values always quoted. <item id=5> is invalid; <item id="5"> is correct. Cleaning up XML matters most for sitemaps, RSS feeds, and configuration files, where a single malformed character makes the entire document unparseable and silently breaks whatever consumes it. JSON vs. XML vs. YAML JSON XML YAML Verbosity Compact Verbose (closing tags) Most compact Comments Not supported Supported Supported Readability Good Moderate Best Attributes No — everything is a key/value Yes No Typical use APIs, web data interchange Sitemaps, RSS, enterprise systems, documents Config files, CI pipelines, Kubernetes Main pitfall No comments allowed Verbosity and escaping Whitespace-sensitive indentation YAML's whitespace sensitivity is worth flagging: indentation is structural, and mixing tabs with spaces breaks the document in ways that are invisible on screen. Since YAML is a superset of JSON, converting between them is straightforward a YAML to JSON converter handles it when you need YAML's readable config in a system that expects JSON. Related Developer Tools JSON to CSV flatten API output into a spreadsheet Mermaid Diagram Editor write flowcharts and sequence diagrams as text Base64 Encoder/Decoder for binary data embedded in JSON payloads A Note on Pasting Data Into Online Tools API responses routinely contain access tokens, customer records, internal endpoints, and credentials. A formatter that uploads your data to a server puts all of that on someone else's infrastructure. Client-side tools process everything in the browser the data never transmits. For debugging production responses, that distinction is the difference between a routine task and an incident. Frequently Asked Questions Why is my JSON invalid? The most common causes are trailing commas, single quotes instead of double quotes, unquoted keys, comments (which JSON doesn't support), and unescaped special characters inside strings. A JSON validator identifies the exact line that fails. Can JSON have comments? No. The JSON specification has no comment syntax, and both // and /* */ cause parse errors. If you need commented configuration, YAML or a format like JSON5 is the usual alternative. What's the difference between beautifying and minifying JSON? Beautifying adds indentation and line breaks for human readability. Minifying removes all unnecessary whitespace to reduce file size for transmission. The data is identical either way. Why does my XML break on an ampersand? & is a reserved character in XML and must be escaped as & . Unescaped ampersands often from URLs inside feeds or sitemaps — make the whole document invalid. Should I use JSON, XML, or YAML? JSON for APIs and data interchange. XML where the format requires it, such as sitemaps, RSS feeds, and established enterprise systems. YAML for configuration files a hu