Kostenloser XML-zu-JSON-Konverter

Was ist XML?

XML (Extensible Markup Language) ist ein Format zum Speichern und Übertragen von Daten. Es verwendet benutzerdefinierte Tags zur Beschreibung der Datenstruktur, wodurch es für Menschen lesbar und weit verbreitet unterstützt ist. Im Gegensatz zu JSON kann XML Attribute auf Elementen enthalten.

Warum XML in JSON konvertieren?

• Geringere Dateigröße · JSON ist kompakter als XML.
• Web-APIs · Die meisten modernen Webdienste verwenden JSON statt XML.
• Einfacheres Parsen · JSON wird direkt JavaScript-Objekten zugeordnet.
• Integration von Legacy-Systemen · Konvertieren Sie alte XML-Daten in das moderne JSON-Format.

Häufig gestellte Fragen

Wie werden XML-Attribute behandelt?

XML-Attribute werden in JSON-Eigenschaften mit dem Präfix „@“ umgewandelt. Zum Beispiel wird Anna zu {"user": {"@id": "1", "#text": "Anna"}}. Dies bewahrt die Unterscheidung zwischen Attributen und Textinhalten.

Was ist mit Namensräumen?

XML-Namensraumpräfixe werden in JSON-Schlüsselnamen beibehalten. Namensraumdeklarationen (xmlns) erscheinen in der Ausgabe als reguläre Attribute, die mit „@xmlns“ beginnen.

Kann ich JSON wieder in XML konvertieren?

Dieses Tool konvertiert nur XML in JSON. Für die Rückkonvertierung verwenden Sie unseren JSON-zu-XML-Konverter, der den Prozess umkehrt und dieselbe Konvention für Attribute und Textknoten verwendet.

Two formats, three decades apart

XML 1.0 became a W3C Recommendation on 10 February 1998. The original editors were Tim Bray (Textuality / Netscape), Jean Paoli (Microsoft) and C. M. Sperberg-McQueen (University of Illinois at Chicago); the Working Group was chaired by Jon Bosak of Sun Microsystems. XML's lineage runs back to SGML (ISO 8879:1986), the document-markup standard that itself grew from IBM's GML in the 1970s. SGML was powerful but daunting; XML's design brief was "design a 'lite' version of SGML", trimming optional features to a profile that could be implemented in a few thousand lines of code while preserving Unicode, namespaces and attribute-rich documents.

JSON (JavaScript Object Notation) was discovered, not designed. Douglas Crockford and Chip Morningstar sent the first JSON message in April 2001 at State Software, deriving the format from JavaScript's object-literal syntax. Crockford registered json.org in 2002 and put up a one-page spec. The format was first formalised as RFC 4627 in July 2006, re-issued as RFC 7159 in 2014, and stabilised as RFC 8259 / STD 90 in December 2017, the same year ECMA-International published ECMA-404. JSON's design intent (per Crockford's retrospective): minimal, language-independent, easy to generate and parse, no version number ("there is no version number"), and deliberately no comments ("I removed comments because I saw people were using them to hold parsing directives").

JSON took over web APIs in the late 2000s as REST replaced SOAP and as XMLHttpRequest gave way to JSON-over-fetch. By 2015 JSON was the default response format of nearly every public API; XML survived in long-tail enterprise SOA, document formats (Office Open XML, OpenDocument), and standards-bound niches.

Where XML and JSON differ

	XML	JSON
Attributes	First-class (<item id="5"/>)	No attributes, everything is a key/value pair
Namespaces	Native (xmlns:prefix="uri")	Flat names; prefix collisions are the app's problem
Comments	<!-- … -->	None per spec
Mixed content	Native (<p>text <b>and</b> markup</p>)	Awkward, needs arrays or stringification
Schema	DTD, XSD 1.0 (2001) / 1.1 (2012), RELAX NG, Schematron	JSON Schema (community spec, draft 2020-12)
Order	Element order is significant per spec	Object key order not guaranteed (most parsers preserve insertion order in practice); arrays are ordered
Numbers	Strings until typed by schema	IEEE 754 double; no integer/float distinction at spec level
Verbosity	High (every value wrapped in tags	Low) punctuation only

Why XML→JSON is fundamentally lossy

There is no W3C-blessed canonical mapping from XML to JSON. Every converter has to invent answers to questions XML allows you to express but JSON has no native vocabulary for. The recurring decisions:

• Attributes vs child elements: XML lets you express the same data both ways. JSON has only one notion (keys on an object), so the converter must invent a marker. The common conventions: BadgerFish uses @ for attributes and $ for text; Parker drops attributes entirely (lossy but simple); JsonML represents elements as arrays with type tags (preserves order and structure); GData / Newtonsoft / xml2js use an @attributes sub-object plus a #text key when needed. This converter follows the GData-style convention: attributes under @attributes, mixed-content text under #text, repeated children become arrays.
• Repeated child elements: if the converter blindly creates one key per child, the second child overwrites the first. Standard fix: detect repetition and emit an array. But this means the JSON shape depends on data, one <book> produces a string, two produce an array of strings. Some consumers want the array form even for one item; some converters expose an "always-array" toggle for specific element names.
• Mixed content: <p>Hello <b>world</b>!</p> intermixes text and elements with significant order. JSON cannot natively express that interleaving without an array of mixed types or a sentinel #text key. Many converters drop the prose between elements; the more conservative ones split it into multiple text-node entries.
• Namespaces: <soap:Envelope xmlns:soap="…"> has both a prefix and a binding URI. Most converters preserve the prefix as part of the JSON key (soap:Envelope) and drop the binding, which is fine as long as the consumer doesn't need to resolve the namespace.
• Comments and processing instructions: usually dropped silently, since JSON has no comment syntax.
• CDATA sections: flattened to plain strings; the <![CDATA[…]]> wrapper is lost.
• Whitespace: XML has xml:space="preserve" for significant whitespace; JSON has no equivalent. Most converters trim whitespace-only text nodes between elements.

When you'd reach for this

• Consuming legacy SOAP services from a modern JS frontend. SOAP responses are XML; converting once at the boundary lets the rest of the app work in JSON.
• RSS / Atom feed processing: both are XML formats; modern news readers and aggregators usually want JSON.
• XML sitemaps (sitemap.xml), converting to JSON makes them easier to inspect and process programmatically.
• OpenStreetMap OSM data: published as XML, frequently needed as JSON for client-side mapping.
• Google Earth KML / GPX files: geographic data formats that come in XML.
• Office Open XML internals: .docx, .xlsx and .pptx are zipped XML files; if you've extracted one and want to inspect its structure as JSON, this is the conversion step.
• SVG manipulation: SVG is XML. Converting to JSON makes it easier to walk and mutate the tree in JavaScript before re-serialising.
• Maven POM, Ant build files, Spring config, Android resources, Apple plists, XBRL financial data, HL7 medical records, MusicXML, NMX legal documents: long-tail XML formats that often need JSON for downstream tooling.

Modern alternatives

• Native JSON APIs. If the upstream service offers a JSON variant, take it. SOAP services typically don't but most modern equivalents do.
• GraphQL. A query language that lets the client request exactly the JSON shape it needs from a typed schema.
• Protocol Buffers (Protobuf), MessagePack, CBOR, Avro. Binary serialisation formats with schemas and much smaller wire sizes than either XML or JSON. Common inside microservice meshes; rarely used at the browser boundary because they need explicit decoding libraries.
• Stay in XML. If the data is genuinely document-oriented (mixed content, deep typed structure, schema validation that matters), XML is the better fit. JSON's strength is API-shaped data; document fidelity isn't its specialty.

More questions

Why does the same XML produce a different JSON shape on different tools?

Because there is no canonical XML→JSON mapping. Each converter picks a convention (BadgerFish, Parker, JsonML, GData-style) and the resulting JSON shapes differ in how attributes are marked, how mixed content is preserved, and how repeated children are arrayed. Round-tripping XML through different converters produces different JSON; round-tripping JSON back to XML through different converters can change attribute placement and even element ordering. For interoperability, document the convention you're using and stick to it.

What about CDATA, comments and processing instructions?

CDATA sections (<![CDATA[…]]>) are flattened to plain string content, the wrapper is gone, but the text inside is preserved verbatim. XML comments (<!-- … -->) and processing instructions (<?xml-stylesheet …?>) are dropped, since JSON has no syntax for either. If you need round-trip fidelity that preserves comments, an XML-only round trip is the right approach.

Will my XML schema (XSD) survive the conversion?

No. XSD describes XML structure and types; JSON Schema is the analogous (separate) standard for JSON. Some advanced tooling can translate XSD to JSON Schema, but it's a lossy operation, XSD has features (mixed content, substitution groups, derived types) that have no clean JSON Schema equivalent. For document validation that matters, run XSD against the original XML, not against the JSON conversion.

Why did JSON win for web APIs?

A few reasons. JSON maps directly to JavaScript objects, so browser-side parsing is one JSON.parse() call away. The format is much smaller, no closing tags, no namespace declarations, no schema baggage. REST replaced SOAP for most public APIs in the late 2000s, and JSON was the natural payload for REST. XML's strengths (strict schemas, namespaces, mixed content) matter for documents and legacy enterprise systems but rarely for "give me the user object." The web optimised for the simpler case.

Does anything get sent to a server?

No. The XML is parsed by the browser's native DOMParser, then walked recursively in JavaScript to build the JSON output. Pasted XML never leaves the page. The tool works offline once it's loaded, which matters when the source XML contains internal API endpoints, customer data, or proprietary schemas you'd prefer not to upload anywhere.

Verwandte Tools