JSON zu XML Konverter

JSON und XML, zwei Formate, zwei Ären

XML (Extensible Markup Language) wurde vom W3C am 10. Februar 1998 als Recommendation standardisiert, die W3C-XML-1.0-Spezifikation, herausgegeben von Tim Bray, Jean Paoli und C.M. Sperberg-McQueen. XML entstand aus SGML (der älteren „Standard Generalised Markup Language“, ISO 8879:1986), indem die komplexesten Features entfernt wurden, um etwas zu produzieren, das das Web realistisch nutzen konnte. Etwa für das erste Jahrzehnt des 21. Jahrhunderts war XML das angenommene Format für jeden strukturierten Datenaustausch, SOAP-Webdienste, RSS-Feeds (RSS 2.0, Dave Winer, 2002), Atom (RFC 4287, 2005), Microsoft Offices Open-XML-Formate (.docx/.xlsx/.pptx, ISO/IEC 29500:2008), Android-XML-Layouts, Java-Property-Dateien, Konfiguration in nahezu jedem Server-Framework. XMLs Stärken sind Namensräume, Attribute, gemischter Inhalt (Text und Kindelemente verschränkt) und ein reichhaltiges Schema-Ökosystem (DTD, XML Schema 1.1, Relax NG). Seine Schwäche ist die Wortfülle, jeder Wert trägt einen öffnenden und schließenden Tag.

JSON (JavaScript Object Notation) wurde 2001 von Douglas Crockford spezifiziert, die json.org-Webseite und sein ursprünglicher Aufsatz „JSON: The Fat-Free Alternative to XML“. JSON ist absichtlich eine Teilmenge der JavaScript-Objekt-Literal-Syntax: Objekte, Arrays, Strings, Zahlen, true/false/null. Standardisiert als RFC 4627 im Juli 2006, verfeinert als RFC 7159 (März 2014) und RFC 8259 (Dezember 2017, aktueller Standard STD 90, parallel auch von ECMA als ECMA-404 veröffentlicht). JSONs Übernahme der Web-APIs von XML vollzog sich grob 2008-2014, der Zeitpunkt fällt mit dem Aufstieg der Single-Page-Apps und der Mobile-API-Ära zusammen. Heute dokumentiert sich nahezu jede öffentliche API als JSON; XML überlebt vor allem in Enterprise-Integration, Dokumentformaten, Konfigurationsdateien und Feed-Formaten. Beide Formate bleiben in aktivem Einsatz, weil sie unterschiedliche Dinge gut kodieren: JSON ist richtig für strukturierte Daten mit einfachen Typen und vorhersehbarer Form; XML ist richtig für Dokumente mit gemischtem Inhalt, Attributen, Namensräumen und rigorosen Schemata.

Wann du wirklich JSON in XML konvertieren musst

• Einen SOAP-Webdienst von einem Nur-JSON-Client aufrufen. SOAP ist by design XML-basiert (der SOAP-Envelope, die WSDL-Service-Beschreibung, die XSD-Schemata). Wenn du Daten in JSON-Form hast und einen SOAP-Request-Body konstruieren musst, ist JSON-zu-XML die Brücke. Üblich in Enterprise-Integration, wenn moderne Microservices mit Legacy-SOAP-Endpunkten reden müssen (Banken, Behörden, Versicherungen, Gesundheits-Austauschsysteme).
• Office-Open-XML-Dokumente aus JSON-Daten generieren. Die Formate .docx, .xlsx und .pptx sind ZIP-Archive von XML-Dateien. Um Office-Dokumente programmatisch aus JSON-gestützten Daten zu erzeugen oder zu modifizieren, geschieht die JSON-zu-XML-Konvertierung an der Grenze zwischen der Datenschicht deiner Anwendung und der Dokumenten-Generator-Bibliothek.
• Einen RSS- oder Atom-Feed aus JSON-Inhalt produzieren. Blogs, News-Sites und Podcast-Plattformen geben RSS/Atom-Feeds zur Syndication aus. Wenn dein CMS die Artikel als JSON speichert, wandelt der Feed-Generierungsschritt die JSON-Einträge in das XML-Format, das das Feed-Reader-Ökosystem erwartet.
• XML-Konfigurationsdateien für Legacy-Anwendungen erzeugen. Viele ältere Enterprise-Anwendungen (Java-Application-Server, .NET-Konfigurationsdateien, Spring-XML-Application-Context) konsumieren ihre Konfiguration als XML. Modernes Infrastructure-as-Code-Tooling arbeitet typischerweise in YAML oder JSON, also sitzt eine JSON-zu-XML-Konvertierung in der Deployment-Pipeline.
• Daten in eine XSLT-Transformation einspeisen. XSLT (XSL Transformations, Spezifikation von Michael Kay, W3C-Recommendation) ist die Standard-XML-Transformationssprache und konsumiert XML-Eingabe. Wenn deine Daten in JSON beginnen und deine Reporting-Engine XSLT-basiert ist, geschieht die Konvertierung an der Eingabegrenze.
• Android-Ressourcendateien erzeugen. Androids strings.xml, colors.xml, dimens.xml und Layout-Dateien sind XML. Lokalisierungs-Pipelines, die Strings für die einfachere Bearbeitung in JSON speichern, konvertieren beim Build in XML.

Das Konvertierungs-Mapping, wo Information überlebt und wo sie verloren geht

JSON und XML haben unterschiedliche strukturelle Primitive, also muss jede Konvertierung Entscheidungen treffen. Das Standard-JSON-zu-XML-Mapping, dem die meisten Konverter (dieser eingeschlossen) folgen:

• JSON-Objekte werden zu XML-Elementen. Jeder Schlüssel wird zu einem Kindelement mit dem Schlüssel als Tag-Namen. {"name": "Alice"} wird zu <name>Alice</name>.
• JSON-Arrays werden zu wiederholten Kindelementen. {"items": [1, 2, 3]} wird zu drei <item>1</item><item>2</item><item>3</item>-Kindern innerhalb des <items>-Wrappers. (Verschiedene Konverter verwenden unterschiedliche Konventionen für den Array-Element-Namen; manche verwenden den Eltern-Namen im Singular, manche ein festes <item>.)
• Strings, Zahlen, Booleans werden zum Textinhalt des Elements. Typinformation wird nicht erhalten, XML behandelt allen Text als Zeichendaten, also würde ein Roundtrip XML → parse → zurück zu JSON serialisieren Zahlen als gequotete Strings emittieren, sofern der Konsument keine Typinferenz anwendet.
• null wird zu einem selbstschließenden leeren Element. {"middle_name": null} wird zu <middle_name/>. Manche Konverter verwenden stattdessen xsi:nil="true".
• Das Wurzelelement umschließt alles. JSON erlaubt ein Top-Level-Array oder einen Skalar; XML verlangt genau ein Wurzelelement. Der <root>-Wrapper (hier konfigurierbar) ist die konventionelle Lösung.

In der Konvertierung verlorene Information: JSONs Unterscheidung zwischen Zahlen und Strings, JSONs Unterscheidung zwischen true/false und „true“/„false“-Strings, JSONs Array-vs-Objekt-Unterscheidung (wenn ein Array zu wiederholten Elementen wird, kannst du allein aus dem XML nicht sagen, ob die Quelle ein einelementiges Array oder einen einzelnen Wert hatte). Potenziell gewonnene, aber von einfachen Konvertern nicht genutzte Information: XML-Attribute (ein JSON-Objekt könnte Schlüssel auf Attribute statt Kindelemente abbilden), XML-Namensräume (JSON hat nichts Äquivalentes), CDATA-Sektionen (zum Einbetten von Text mit XML-Sonderzeichen). Für eine roundtrip-sichere JSON-zu-XML-Konvertierung, die Typinformation erhält, kodieren die BadgerFish-Konvention oder die Parker-Konvention JSON-Typen als namespacebehaftete XML-Attribute, dieses Werkzeug erzeugt die einfachere, lesbarere Form statt der roundtrip-sicheren Form.

XML-Tag-Namen-Beschränkungen, die JSON-Schlüssel nicht haben

JSON-Objektschlüssel sind beliebige Strings, jedes Unicode ist erlaubt. XML-Element-Namen sind weit eingeschränkter: sie müssen mit einem Buchstaben oder Underscore beginnen (nicht mit einer Ziffer, einem Bindestrich oder Punkt), können Buchstaben, Ziffern, Bindestriche, Underscores und Punkte enthalten (keine Leerzeichen, kaum Satzzeichen), sind case-sensitiv, und dürfen nicht mit dem reservierten Präfix xml in irgendeiner Groß-/Kleinschreibung beginnen. JSON-Schlüssel mit Leerzeichen ("first name": "Alice"), Schlüssel, die mit Ziffern beginnen ("3rd_choice"), oder Schlüssel mit Sonderzeichen ("@type", "$value") können nicht direkt als XML-Element-Namen verwendet werden. Die meisten Konverter (dieser eingeschlossen) zermatschen ungültige Zeichen still, ersetzen Leerzeichen durch Underscores, stellen Schlüsseln, die mit Ziffern beginnen, einen Underscore voran, lassen die meiste Interpunktion fallen. Sei dir dessen beim Roundtripping bewusst: ein JSON-Dokument mit nicht-XML-sicheren Schlüsseln läuft nicht identisch durch XML zurück.

Wo XML 2026 noch herrscht

XML ist 2026 nicht im Rückzug, es hat sich nur in spezifische Nischen eingerichtet. Dokumentformate: Office Open XML (Microsoft Office), OpenDocument (LibreOffice), EPUB-eBooks, SVG (W3C-Recommendation 4. September 2001), MathML, XHTML. Konfiguration: Java-Application-Server, Spring-XML-Kontexte, Maven-POMs, Android-XML-Ressourcen, .NET-app.config- und web.config-Dateien. Feeds: RSS 2.0, Atom 1.0 (RFC 4287), Podcast-Feeds (die iTunes-RSS-Erweiterungen). Gesundheits- und Behörden-Austausch: HL7 v3, FHIR (das jetzt JSON als Alternative anbietet, aber die XML-Form bleibt stark im Einsatz), DocBook, NewsML, Banking-ISO 20022. Standardisierungsgremien: Nahezu jedes IETF- und W3C-Spezifikationsbeispiel verwendet XML. XMLs Wortfülle ist in diesen Domänen ein Feature: es ist selbstbeschreibend, die Validierung gegen ein Schema ist gut etabliert, und XSLT-Transformationen zwischen XML-Dialekten sind ein reifes Werkzeug. Das Format wird nicht verschwinden; die JSON-zu-XML-Konvertierung ist die Brücke zwischen modernem Daten-Tooling und diesen etablierten XML-nativen Systemen.

Datenschutz: Konvertierung nur im Browser

JSON, das in einen Konverter eingefügt wird, enthält oft echte Produktionsdaten, API-Antworten mit Nutzer-IDs, interne Entitäts-IDs, die Geschäfts-Taxonomie verraten, Konfigurationswerte mit Endpunkt-URLs und Feature-Flags, Tokens, noch unveröffentlichten Entwurfsinhalt. Server-seitige Konverter nehmen eine Kopie jeder Eingabe in ihre Logs auf. Dieser Konverter parst dein JSON mit dem im Browser eingebauten JSON.parse(), durchläuft den resultierenden Objektbaum in JavaScript und emittiert XML als String, alles innerhalb deines Browser-Tabs. Verifiziere im Network-Tab der DevTools, während du auf Convert klickst (es feuert keine Anfrage), oder schalte die Seite nach dem Laden offline (Flugmodus), und der Konverter funktioniert weiter. Sicher für Produktions-API-Antworten, interne Konfiguration, Entwurfsinhalt oder jedes JSON, das du nicht auf der Festplatte eines Fremden sehen wolltest.

Häufige Fragen

Wie werden JSON-Arrays konvertiert?

Jedes Array-Element wird zu einem separaten Kindelement. {"colors": ["red", "blue"]} wird zu <colors><item>red</item><item>blue</item></colors>. Der konventionelle Element-Name für unbenannte Array-Einträge ist <item>. Wenn dein nachgelagerter Konsument eine andere Konvention erwartet (z. B. die Singularform des Eltern-Namens wie <color>), musst du das XML nachbearbeiten oder einen anderen Konverter verwenden, der benutzerdefinierte Array-Element-Benennung unterstützt.

Funktioniert das mit großen JSON-Dateien?

Ja, weil alles im Browser läuft, ist die praktische Obergrenze der verfügbare Speicher deines Geräts. Zehntausende Zeilen JSON werden auf einem modernen Laptop in deutlich weniger als einer Sekunde konvertiert. Sehr große Eingaben (Mehrere MB) können den Tab kurz einfrieren, während der Parser den Baum durchläuft. Für Batch-Konvertierung großer Datensätze ist ein Skript mit einem server-seitigen Konverter (xml2js in Node, dicttoxml in Python) angemessener.

Wird mein JSON auf einen Server hochgeladen?

Nein. Die Konvertierung läuft komplett in deinem Browser, eingefügtes JSON verlässt dein Gerät nie. Verifiziere im Network-Tab der DevTools, während du auf Convert klickst (es feuert keine Anfrage), oder schalte die Seite nach dem Laden offline (Flugmodus). Sicher für Produktions-API-Antworten, interne Konfiguration oder beliebige Daten, die du nicht extern teilen wolltest.

Kann ich einige JSON-Schlüssel zu XML-Attributen statt zu Kindelementen machen?

Dieser Konverter emittiert alle JSON-Schlüssel als Kindelemente, nicht als Attribute. Die Konvention, die manche Konverter verwenden (Schlüssel mit Präfix @ werden zu Attributen ("@id": 5 → id="5" beim Eltern-Element)) ist die BadgerFish-Konvention. Wenn dein nachgelagerter Konsument bestimmte Werte als Attribute verlangt, brauchst du einen benutzerdefinierten Konverter, der die Konvention versteht, oder bearbeite das resultierende XML von Hand.

Was passiert mit JSON-Schlüsseln, die Leerzeichen oder ungültige XML-Zeichen enthalten?

XML-Element-Namen haben strengere Regeln als JSON-Schlüssel: sie müssen mit einem Buchstaben oder Underscore beginnen, dürfen keine Leerzeichen enthalten und verbieten die meiste Interpunktion. Schlüssel mit ungültigen Zeichen werden bereinigt, Leerzeichen werden zu Underscores, führenden Ziffern wird ein Underscore vorangestellt, Sonderzeichen werden entfernt. Das bedeutet, ein Roundtrip JSON → XML → JSON erzeugt möglicherweise nicht exakt die ursprünglichen Schlüsselnamen. Wenn deine Daten ungewöhnliche Schlüssel haben, prüfe die Ausgabe, um sicherzustellen, dass die Verstümmelung nichts Wichtiges kaputtgemacht hat.

Verwandte Tools