Working with JSON, XML and YAML: Format, Validate and Convert

Every developer has pasted a wall of minified JSON and hunted for the one missing comma. Formatting and validation tools turn that into a two-second fix — but the interesting problems in this area are not syntax errors. They are the quiet mismatches between formats that look interchangeable and are not.

This guide covers formatting and validating JSON, XML and YAML, and the specific places converting between them loses information.

Formatting and validating JSON

JSON Formatter pretty-prints with proper indentation and reports the exact line and column of a syntax error. Most failures come from a short list of causes:

• A trailing comma after the last element. Legal in JavaScript, illegal in JSON.
• Single quotes instead of double. JSON permits only double quotes, for both keys and string values.
• Unquoted keys. Also legal in JavaScript object literals, also invalid JSON.
• An unescaped control character — most often a raw newline inside a string.
• A leading byte-order mark, invisible in most editors, which breaks strict parsers.

Worth knowing: JSON has no comment syntax. Any file with // or /* */ is not JSON, whatever its extension. Several tools accept a superset called JSON5 or JSONC; a strict parser will reject them.

The number problem nobody warns you about

JSON numbers are arbitrary precision in the specification, but almost every parser reads them into a double-precision float. Doubles represent integers exactly only up to 2^53 − 1, which is 9,007,199,254,740,991.

This matters immediately in practice. A 64-bit database ID, a Twitter snowflake ID, or a large financial figure will silently lose its final digits after a round trip. The value does not error — it simply comes back different.

The standard fix is to transmit large integers as strings. If you control the API, do that. If you do not, check whether your parser offers a big-integer mode before assuming the data is intact.

The same caution applies to decimals: 0.1 + 0.2 is not 0.3 in any IEEE 754 float, so monetary values belong in strings or in integer minor units, never in JSON floats.

YAML is not a safer JSON

YAML is far more readable, which is why it dominates configuration. It is also considerably more surprising.

Indentation is structural, and tabs are forbidden. A tab character anywhere in the indentation is a parse error. Most YAML bugs are whitespace.

Unquoted scalars are type-guessed. This is the source of the format's most notorious behaviour. In YAML 1.1, yes, no, on and off parse as booleans — which famously means a country code NO becomes false unless quoted. Version numbers like 1.10 become the float 1.1, losing the zero. A MAC address or a time like 12:30 may be read as a sexagesimal number.

YAML 1.2 narrowed the boolean rule to true and false, but many parsers still implement 1.1 semantics. The reliable defence is to quote any scalar whose type you care about.

Leading zeros change the base. A zip code written as 01234 may parse as octal.

Convert with YAML to JSON and inspect the result — the conversion is the fastest way to see what a parser actually thinks your file says.

XML: verbose, precise, still unavoidable

XML carries a distinction the other two formats lack: attributes versus elements. There is no natural equivalent in JSON, which is why XML-to-JSON conversion is never lossless without a convention — attributes are typically prefixed with @ and text content stored under a key like #text.

XML also has namespaces, comments, processing instructions, mixed content and a schema language with real type validation. JSON Schema exists and is good, but XSD validation is more mature.

Use XML Formatter to pretty-print and XPath Tester to query. XPath remains one of the genuinely excellent parts of XML — there is no equally expressive standard query language for JSON.

What conversion loses

Treat every conversion as lossy until proven otherwise.

Direction	What is lost
YAML → JSON	Comments, anchors and aliases, multi-document files, key order guarantees
XML → JSON	Attribute/element distinction, namespaces, comments, mixed content, node order
JSON → CSV	All nesting; arrays and objects must be flattened or serialised
Any → JSON	Dates and times, which JSON has no native type for

The last row causes the most trouble in practice. JSON has no date type, so timestamps travel as strings and every consumer must agree on the format. Use ISO 8601 with an explicit timezone offset, and never a bare local time.

CSV loses more than people expect. It has no type system, no nesting, and no universally agreed quoting rule — JSON to CSV has to flatten structure to produce a table, and that flattening cannot be reversed automatically.

Validate against a schema, not just a parser

A file that parses is not a file that is correct. Parsing proves the syntax is well-formed; it says nothing about whether the required fields are present or the values are sensible.

JSON Schema is the practical tool here: it expresses required properties, types, ranges, enumerated values and conditional requirements. For XML, XSD does the same job with stronger typing. For YAML, validate the JSON equivalent after conversion, since the data models align closely enough.

Comparing two files

Diffing structured data as plain text produces noise, because reordered keys and reindented blocks read as changes when nothing meaningful moved. A structural diff compares the parsed trees instead — JSON Diff, XML Diff and YAML Diff do this, so reformatting shows as no change and a genuinely altered value stands out.

A note on pasting real data

Configuration files and API responses are exactly the material that carries secrets: connection strings, bearer tokens, private keys, customer records. Pasting them into an online formatter that processes server-side means transmitting them to a third party.

Every tool linked here runs entirely in your browser, so the text stays on your machine. That property is worth checking on any tool you use for this — see is it safe to paste production data into online tools for how to verify it yourself.