Free XML & YAML Tools

Which tool for which problem

Most XML and YAML work falls into three jobs: making an unreadable file readable, getting data into JSON for a script, and finding the character that broke the parser.

The formatter is for the SOAP envelope or pom.xml that arrives as one 40,000-character line. The converters are for when something downstream only speaks JSON: a jq pipeline, a Postman test.

YAML to JSON is usually about validation, not conversion

Plenty of people run YAML through a converter without wanting the JSON: they want to know whether the file parses, and whether values came out as intended types. The second answer depends on the YAML version the receiving parser implements.

YAML 1.1 resolvers, still used by PyYAML and Ruby's Psych, read bare yes, no, on and off as booleans in lower, Title or upper case (NO resolves, nO does not). PyYAML turns country: NO into {"country": false}, and a workflow's top-level on: into the boolean key true. The YAML 1.2 core schema drops that, so js-yaml 4 and later leave NO a string.

Other version-dependent readings:

• id: 0755 is octal 493 under 1.1, decimal 755 under 1.2
• time: 12:30 is the sexagesimal integer 750 under 1.1, a string under 1.2
• version: 1.20 loses its trailing zero under both, arriving as 1.2

Converting shows which reading you got, since JSON quotes strings and leaves numbers, booleans and null bare. Quote the source value (country: "NO") and every parser agrees.

Where XML to JSON gets lossy

XML carries information JSON has no slot for, so every converter decides on your behalf.

Attributes and child elements are separate in XML but share one object in JSON, so converters prefix attributes (commonly @) and park element text under #text. <price currency="GBP">19.99</price> becomes {"price": {"@currency": "GBP", "#text": "19.99"}}, not the bare 19.99 you expected, and it stays a string: XML text is untyped without a schema.

The bigger trap is repeated elements. Three <item> children become a JSON array; one becomes a single object, because nothing in the document says it was meant to be a list. Code doing data.items.item.map(...) passes testing and throws the first time a customer has one order. Normalise with [].concat(data.items.item).

Reading the error message

Parsers stop at the first structural problem, and the reported line is where it noticed, not where you went wrong:

• "Content is not allowed in prolog", the Xerces wording, means bytes before the <?xml declaration: a UTF-8 byte order mark (EF BB BF), stray whitespace, or an HTML error page instead of your feed.
• A bare & in XML text is invalid and must be written &, which is why pasted query strings break.
• YAML's "mapping values are not allowed in this context" usually means an unquoted colon-and-space inside a value.
• Tabs are illegal as YAML indentation at any depth, and editors that convert leading spaces cause it constantly.

Common questions

Does my file get uploaded anywhere? No. Parsing runs in JavaScript in your own tab, so a Kubernetes secret never leaves the machine. Watch the DevTools Network tab while you convert: no request carries your document.

Why do my YAML comments vanish after conversion? JSON has no comment syntax, so the parser discards them. A # opens a comment only at line start or after whitespace, so one inside a quoted string survives. Anchors and aliases keep their values but lose their sharing: *base expands into a full copy, so a round trip returns a longer file.

Can I convert JSON back into XML? Not reliably in one step. A converter has to invent a root element name, decide which keys become attributes rather than child elements, and flatten arrays into repeated siblings, since XML has no array type.

How big a file can these handle? The limit is browser memory, not a server quota; a few megabytes is fine on a laptop. A several-hundred-megabyte dump will lock the tab: the whole document is held as a tree of objects costing several times the file size in RAM. Parse those locally with a streaming reader like lxml's iterparse.

Related