JSON-zu-XML-Konverter

Q: Warum ist JSON-zu-XML nicht immer verlustfrei?

JSON kennt explizite Zahl-, Boolean- und null-Typen; XML kennt nur Text. JSON erlaubt Schlüssel mit Leerzeichen oder Sonderzeichen; XML-Elementnamen nicht. Arrays auf der obersten Ebene haben kein offensichtliches XML-Äquivalent. Die Seite überbrückt das mit Heuristiken (Wrapper-Element root, ungültige Schlüssel werden bereinigt).

Q: Wie werden Array-Werte in XML dargestellt?

Jedes Array-Element wird zu einem Geschwisterelement mit demselben Namen. [{a:1},{a:2}] → 1 2 . Die Verpackung ist konfigurierbar; manche Seiten lassen dich den Singular-Namen explizit wählen.

JSON-Eingabe

Stammelement

XML-Ausgabe

Einrückung

Zeilen: 1Zeichen: 0Bytes: 0

Was ist JSON-zu-XML-Konvertierung?

JSON zu XML konvertiert strukturierte JSON-Daten in XML-Markup, damit Daten zwischen Systemen mit unterschiedlichen Austauschformaten übertragen werden können. JSON arbeitet mit Objekten, Arrays, Zahlen, Strings, Booleans und null, während XML Elemente, Attribute, Textknoten und Namespaces kennt. Deshalb ist die Umwandlung nicht immer eins zu eins: Array-Namen, Attribute, leere Werte, Sonderzeichen und Reihenfolge müssen sinnvoll abgebildet werden. Das Werkzeug ist nützlich für SOAP-nahe Integrationen, alte Unternehmenssysteme, Datenmigration, Testpayloads und Dokumentation. Für produktive Schnittstellen sollte das Ergebnis gegen das erwartete XSD oder Partnerformat validiert werden, weil korrektes XML nicht automatisch fachlich akzeptiertes XML ist.

Anleitung

So geht's

JSON-Daten im linken Eingabefeld einfügen oder eingeben
Optional den Namen des Wurzelelements anpassen
Einrückung wählen (2 Leerzeichen, 4 Leerzeichen oder Tab)
Das konvertierte XML erscheint rechts mit Syntaxhervorhebung.
Auf Kopieren oder Herunterladen klicken, um das Ergebnis zu speichern

Konvertierungsprüfungen

Arrays, Null-Werte und attributähnliche Felder prüfen – JSON und XML modellieren Daten unterschiedlich.
Vor dem Einfügen in API-Anfragen, Konfigurationsdateien oder Test-Fixtures einen stabilen Wurzelelementnamen wählen.

Anwendungsfälle

JSON-Payloads für reine XML-Schnittstellen konvertierenEinige ältere Endpunkte, Import-Jobs und Drittanbietersysteme erwarten noch XML, auch wenn die Quelldaten als JSON vorliegen. Dieser Konverter lässt ein Stammelement wählen, bewahrt wiederholte Array-Werte als wiederholte item-Knoten und escappt XML-sensitive Zeichen vor der Ausgabe. Das Ergebnis ist ein Ausgangspunkt für SOAP-Anfrage-Envelopes, EDI-Test-Fixtures oder Partner-Payloads, die noch nicht auf JSON migriert sind.

Lesbare XML-Beispiele aus strukturierten Daten erstellenDie Einrückungsoptionen nutzen, um ein verschachteltes JSON-Beispiel in XML zu verwandeln, das sauber genug für Dokumentation, Tickets oder Vertragsbesprechungen ist. Ungültige oder leere Stammelementnamen werden abgefangen, sodass schnelle Experimente an kleinen Namensfehlern nicht scheitern. Die eingerückte Form ist im Code-Review auch leichter zu vergleichen als eine einzeilige komprimierte Version.

Sonderfälle testen, bevor XML manuell bearbeitet wirdNull-Werte, leere Objekte, leere Arrays, Arrays mit Basistypen und verschachtelte Datensätze erzeugen jeweils unterschiedliche XML-Strukturen. Das Durchlaufen des Beispiels durch den Konverter macht diese Entscheidungen sichtbar, bevor das Ergebnis in einen Mapper, SOAP-Client oder eine Importvorlage eingefügt wird. Die Konvertierung nach jeder Schema-Änderung wiederholen, damit das XML mit dem JSON-Vertrag synchron bleibt.

JSON-Felder gezielt auf Attribute oder Kindelemente abbildenWählen, welche Schlüssel zu Attributen und welche zu Kindelementen werden, da einige ältere Schemas ID-ähnliche Felder als Attribute behandeln, während Beschreibungen als Elemente bleiben. Nach jeder Mapping-Änderung erneut ausführen, um zu bestätigen, dass die Reihenfolge der Pflichtattribute und Namespace-Präfixe noch mit dem erwarteten XSD übereinstimmen. Die Attributreihenfolge in XML ist semantisch nicht bedeutsam, aber die Elementreihenfolge kann von einer XSD-Sequenz verlangt werden.

Das Ergebnis gegen das XSD eines Partners validierenNach der Konvertierung das XML in xmllint --schema oder einen Online-XSD-Validator einspeisen, um fehlende Pflichtelemente, falsche Typen und Reihenfolgeregeln zu erkennen, die der Konverter allein nicht durchsetzen kann. Ein wohlgeformtes XML-Dokument ist nicht dasselbe wie eines, das ein nachgeschalteter Partner akzeptiert, und die Wahl zwischen Attribut und Element kann ändern, welche Felder das XSD als Pflicht betrachtet. Solange am JSON oder den Konvertierungsregeln iterieren, bis der Validator eine saubere Übereinstimmung meldet.

Technisches Prinzip

JSON (RFC 8259, abgeleitet von JavaScript-Objektliteralen) und XML (W3C XML 1.0, ursprünglich 1998) sind beides baumstrukturierte Serialisierungsformate, aber ihre Grammatiken unterscheiden sich. JSON hat Objekte (Schlüssel/Wert-Maps mit String-Schlüsseln), Arrays (geordnete Listen) und sechs Skalartypen (String, Number, Boolean, null sowie die Strukturtypen). XML hat Elemente (Start-/End-Tag-Paare, die Text oder Kindelemente umschließen), Attribute (Schlüssel/Wert-Paare im Start-Tag), Textknoten, Kommentare, Verarbeitungsanweisungen und CDATA-Abschnitte. Die Konvertierung ist eine Strukturtransformation ohne kanonische Antwort — jede existierende Konvention (BadgerFish, JSONML, SOAP/RPC-Kodierung, OOXMLs flaches Schema, XBRLs Linkbase-Format) ist eine andere Regel für dieselbe Eingabe. Die Entscheidung 'Attribut vs. Kindelement' ist die zentrale Mehrdeutigkeit. Die einzigen Metadaten in JSON leben im Schlüsselnamen, daher sagt ein JSON-Objekt wie {"id": "42", "name": "Alice", "admin": true} nicht, welche Schlüssel 'Metadaten' und welche 'Daten' sind. Drei gängige Konventionen: (1) die Standardeinstellung der Seite — Skalare werden zu Textinhalten, während der ursprüngliche JSON-Schlüssel eines verschachtelten Attributbeutels (erkannt daran, dass es ein Nicht-Array-Objekt ist, dessen Werte ausschließlich Skalare sind) zu einem XML-Attribut mit dem Präfix `@` wird (BadgerFish-Konvention). (2) JSONML — jedes JSON-Objekt wird zu einem Element, wobei der Schlüssel 'tag' der Elementname ist, der Schlüssel 'attr' die Attribut-Map und Kindeinträge die Kinder. (3) oData / Atom — JSON-Objekte werden zu Elemente und Arrays werden inline mit einem Wrapper-Element für den Array-Namen eingebettet. Jede Regel ist für einen bestimmten nachgelagerten Konsumenten nachweislich korrekt und für einen anderen nachweislich falsch, weshalb kein XML-Konverter jemals universell akzeptiert wurde. Arrays sind die zweite Mehrdeutigkeit. JSON-Arrays sind geordnete Listen; XML hat keinen nativen Array-Typ. Die drei Standardlösungen: (a) Kindelemente wiederholen (die Standardeinstellung der Seite, die OOXML/SOAP-Konvention): [1, 2, 3] → <root><item>1</item><item>2</item><item>3</item></root>. (b) In einen Container wrappen: <root><items><item>1</item>...</items></root>. (c) Das Array als einzelnen getrennten String kodieren und das Trennzeichen dokumentieren (CSV-in-XML, nur wenn der Konsument es parsen kann). Jede ist für ein anderes nachgelagertes XSD korrekt; der Konvertierungsschritt muss wissen, welches ausgegeben werden soll. XML-Elementnamen müssen gültige QName-Token sein (XML 1.0 §2.3 / XML Namespaces 1.0 §3): Sie müssen mit einem Buchstaben, Unterstrich oder Doppelpunkt beginnen, gefolgt von Buchstaben, Ziffern, Bindestrichen, Unterstrichen, Punkten oder Doppelpunkten. JSON erlaubt Schlüssel wie '123' oder 'first name', die dagegen verstoßen — der Konverter muss sie entweder umbenennen (zu first_name sluggen, mit _ vorfixen) oder ablehnen. JSON-String-Inhalte benötigen auch Entity-Escaping in Elementtext und Attributwerten: `&` → `&`, `<` → `<`, `>` → `>` (nur in Text in älterem XML erforderlich, aber immer sicher), `"` → `"` und `'` → `'` in Attributen, und jedes Zeichen außerhalb des Codierungsbereichs als `&#xHHHH;`. Die fünf eingebauten Entitäten plus numerische Zeichenreferenzen sind in XML obligatorisch; HTMLs zusätzliche benannte Entitäten (` `, `©`) sind in reinem XML nicht definiert und benötigen bei Verwendung eine explizite DOCTYPE. Das Ausgabedokument benötigt auch eine Prolog- und Namespace-Deklaration: Zuerst `<?xml version="1.0" encoding="UTF-8"?>`, dann alle xmlns-Deklarationen. Wenn das Zielsystem Namespaces verwendet (SOAP nutzt `http://www.w3.org/2003/05/soap-envelope`, XSLT nutzt `http://www.w3.org/1999/XSL/Transform`), werden die Präfixzuordnungen als `xmlns:prefix="uri"`-Attribute am Stamm-Element hinzugefügt. JSON hat kein Namespace-Konzept, daher ist die Wahl der zu verwendenden URI projektspezifisch. Für leere Werte wird JSON null üblicherweise als `<key xsi:nil="true"/>` (die XML-Schema-Konvention) oder `<key></key>` (die Leer-Element-Konvention) ausgedrückt. Der Konverter wählt eine Variante; die richtige Antwort hängt von der XSD-Validierung des Konsumenten ab. Für die umgekehrte Richtung (XML → JSON) gelten dieselben Mehrdeutigkeiten umgekehrt: Attribute werden zu einem `@attributes`-Schlüssel in BadgerFish, CDATA wird zu einem `$`- oder `#text`-Schlüssel, gemischte Inhaltselemente (Text + Kindelemente verschachtelt) haben keine saubere JSON-Darstellung und werden üblicherweise als String-Konkatenation ausgegeben. Praxisnahe Konverter bieten immer Optionen für 'Attribut-Schlüssel', 'Text-Schlüssel' und 'Array-Wrapper' — daran führt kein Weg vorbei.

JSON (RFC 8259) und XML (W3C XML 1.0, 1998) sind beides baumstrukturierte Serialisierungsformate; die Konvertierung ist eine Strukturtransformation ohne kanonische Antwort, daher koexistieren mehrere Konventionen (BadgerFish, JSONML, SOAP, OOXML) für dieselbe Eingabe.
Attribut vs. Kindelement: Skalare werden standardmäßig zu Textinhalten; verschachtelte Attributbeutel-Objekte (nur Skalar-Werte) werden zu @-präfixierten Attributen (BadgerFish). JSONML verwendet 'tag'-/ 'attr'-Schlüssel. oData / Atom verwendet Wrapper-Elemente.
Arrays: Die Standardeinstellung der Seite wiederholt Kindelemente (OOXML/SOAP-Konvention). Alternativen: In ein Container-Element wrappen oder als getrennten String kodieren. Die Array-Reihenfolge von JSON wird in der XML-Ausgabe beibehalten.
Regeln für XML-Elementnamen: Müssen mit einem Buchstaben, Unterstrich oder Doppelpunkt beginnen, gefolgt von Buchstaben/Ziffern/Bindestrichen/Unterstrichen/Punkten/Doppelpunkten (XML 1.0 §2.3). JSON-Schlüssel wie '123' oder 'first name' sind ungültige XML-Namen und müssen geslugged oder abgelehnt werden.
Entity-Escaping: `&` → `&`, `<` → `<`, `>` → `>`, `"` → `"`, `'` → `'`, jedes andere Codierungszeichen als `&#xHHHH;`. Die 5 eingebauten Entitäten sind obligatorisch; HTML-Extras wie ` ` benötigen eine explizite DOCTYPE.
Dokumentprolog: `<?xml version="1.0" encoding="UTF-8"?>` ist die Standard-Erste Zeile. xmlns-Deklarationen am Stamm-Element deklarieren Namespace-Präfixe; JSON hat kein Namespace-Konzept, daher wählt der Konverter pro Projekt.
JSON null → XML: Entweder `<key xsi:nil="true"/>` (XML-Schema-Konvention) oder `<key></key>` (Leer-Element). Die Wahl muss zum XSD des Konsumenten passen, sonst schlägt die Validierung fehl.
Die umgekehrte Richtung XML → JSON hat dieselben Mehrdeutigkeiten: CDATA-Abschnitte werden zu `$`- oder `#text`-Schlüsseln (BadgerFish), gemischte Inhaltselemente (Text + Kindelemente verschachtelt) haben keine saubere JSON-Form und werden üblicherweise zu einem String konkateniert.

Beispiele

Objekt -> Element

{"name": "Alice"}
->
&lt;root>
  &lt;name>Alice&lt;/name>
&lt;/root>

Array -> Elemente

[1, 2, 3]
->
&lt;root>
  &lt;item>1&lt;/item>
  &lt;item>2&lt;/item>
  &lt;item>3&lt;/item>
&lt;/root>

Verschachtelte Struktur

{"user": {"name": "Alice", "age": 25}}
->
&lt;root>
  &lt;user>
    &lt;name>Alice&lt;/name>
    &lt;age>25&lt;/age>
  &lt;/user>
&lt;/root>

FAQ

Wie bildet der Konverter JSON auf XML ab?

Jedes JSON-Objekt wird zu einem XML-Element. Objektschlüssel werden zu Namen von Kindelementen; primitive Werte werden zu Element-Text. Arrays wiederholen das Elternelement. Sonderzeichen im Text werden escaped (& → &, < → <).

Warum ist JSON-zu-XML nicht immer verlustfrei?

JSON kennt explizite Zahl-, Boolean- und null-Typen; XML kennt nur Text. JSON erlaubt Schlüssel mit Leerzeichen oder Sonderzeichen; XML-Elementnamen nicht. Arrays auf der obersten Ebene haben kein offensichtliches XML-Äquivalent. Die Seite überbrückt das mit Heuristiken (Wrapper-Element root, ungültige Schlüssel werden bereinigt).

Wie werden Array-Werte in XML dargestellt?

Jedes Array-Element wird zu einem Geschwisterelement mit demselben Namen. [{a:1},{a:2}] → <items><item><a>1</a></item><item><a>2</a></item></items>. Die Verpackung ist konfigurierbar; manche Seiten lassen dich den Singular-Namen explizit wählen.

Was ist mit JSON-Schlüsseln, die keine gültigen XML-Namen sind?

XML-Elementnamen dürfen nicht mit einer Ziffer beginnen, keine Leerzeichen enthalten und bestimmte Symbole nicht verwenden. Die Seite ersetzt ungültige Zeichen durch Unterstriche oder packt sie in CDATA. Das Ergebnis ist gültiges XML, aber der Round-Trip ist nicht exakt.

Bleiben JSON null und Booleans erhalten?

null wird je nach Einstellung zu einem leeren Element oder ganz weggelassen. true/false werden zum Literaltext „true“ oder „false“. Es gibt keinen XML-Standard für diese Typen – nachgelagerte Parser müssen die Typen selbst interpretieren.

Kann ich XML-Attribute hinzufügen?

JSON kennt kein Attributkonzept, daher erzeugt der Generator standardmäßig nur Elemente. Manche Konverter nutzen ein spezielles Schlüssel-Präfix (z. B. @id), um Attribute anzudeuten – schau in die Optionen, wenn die Attribut-Ausgabe für dein XML-Schema wichtig ist.

Läuft die Konvertierung lokal?

Ja. JSON-Parsing und XML-Erzeugung laufen in deinem Browser. Eingaben werden nicht hochgeladen.