XML-zu-JSON-Konvertierung: Konventionen, Fallstricke und Codebeispiele

Sie holen eine Antwort von einem SOAP-Endpunkt, einem RSS-Feed oder einer sitemap.xml ab, und es ist XML. Ihr Stack ist JSON-nativ: JavaScript im Frontend, REST in der Mitte, ein Dokumentenspeicher ganz unten. Sie müssen also XML in JSON konvertieren und greifen zu einem Parser in der Erwartung, dass es ein Einzeiler wird.

Meistens ist es das auch, bis das Ergebnis Sie beißt. Ein Array, das Sie erwartet haben, entpuppt sich als einzelnes Objekt. Ein id-Attribut verschwindet. Eine Postleitzahl wie 01234 kommt als Zahl 1234 zurück. Keiner dieser Fälle ist ein Fehler in Ihrem Parser. Sie sind die Folge davon, dass zwei Datenmodelle aufeinander abgebildet werden, die nicht zusammenpassen, und der einzige Weg, XML zuverlässig in JSON zu konvertieren, besteht darin, die Konventionen zu verstehen, die diese Lücke überbrücken.

Dieser Leitfaden erklärt, warum es diese Konventionen gibt, vier Wege zur Konvertierung (Browser, JavaScript, Python, CLI), die @_- und #text-Regeln, die jede größere Bibliothek teilt, die fünf Fallstricke, die zu stillem Datenverlust führen, und wie Sie JSON für einen sauberen Hin- und Rückweg wieder in XML konvertieren. Die Beispiele sind echt und ausführbar. Fügen Sie sie in Node, Python oder eine Shell ein, und sie erzeugen die in den Kommentaren gezeigte Ausgabe.

Warum XML-zu-JSON Konventionen braucht (nicht nur eine Umformatierung)

XML und JSON sehen oberflächlich ähnlich aus, denn beide sind Bäume aus benannten, verschachtelten Daten, aber ihre zugrundeliegenden Modelle weichen auf eine Weise voneinander ab, die ins Gewicht fällt. XML-Elemente können Attribute tragen, gemischten Inhalt enthalten (Text verschachtelt mit Kindelementen) und unter Namespaces leben. JSON kennt keines dieser Konzepte. Es hat Objekte, Arrays und vier skalare Typen. Das eine in das andere zu konvertieren ist keine Umformatierung; es ist eine Übersetzung zwischen zwei Grammatiken, von denen die eine Wörter hat, die die andere nicht buchstabieren kann.

Bevor Sie irgendetwas konvertieren, lohnt es sich zu prüfen, ob die Quelle tatsächlich gültig ist. Ein einzelnes nicht maskiertes & oder ein nicht passender Tag wird beim Parser abgewiesen, daher erspart Ihnen ein Durchlauf der Eingabe durch einen XML-Formatierer zur vorherigen Prüfung der Wohlgeformtheit eine Runde verwirrender Fehler.

Hier laufen die beiden Modelle auseinander:

Dimension	XML	JSON
Knotentypen	Elemente, Attribute, Text, gemischter Inhalt	Objekte, Arrays, String, Number, Boolean, null
Wurzelbedingung	genau ein Wurzelelement erforderlich	keine Wurzelbedingung
Attribute	ja (`id="P01"`)	keine (benötigt eine `@_`-Konvention)
Wiederholte Elemente	gleichnamige Geschwister sind erlaubt	Objektschlüssel dürfen sich nicht wiederholen (benötigt eine Array-Konvention)
Typsystem	Text ist untypisiert — alles ist ein String	native Typen
Namespaces	ja (`xmlns`)	keine

Weil die Modelle nicht übereinstimmen, ist jede XML-zu-JSON-Konvertierung konventionsgesteuert, keine verlustfreie Umformatierung. Die gute Nachricht ist, dass die Konventionen nicht willkürlich sind: fast-xml-parser (Node.js), xmltodict (Python) und JAXB (Java) haben alle auf dieselben zwei Markierungen konvergiert, nämlich @_ für Attribute und #text für den Text gemischten Inhalts. Lernen Sie sie einmal, und sie lassen sich auf alle Laufzeitumgebungen übertragen. Aus demselben Grund tauchen Diskrepanzen in der Datenform auch bei anderen Konvertierungen auf, etwa bei den Fragen zur Typinferenz im CSV-zu-JSON-Konvertierungsleitfaden.

XML in JSON konvertieren: 4 Methoden

Wählen Sie die Methode, die zu Ihrem Kontext passt: ein schnelles einmaliges Einfügen, ein Node-Dienst, eine Python-Pipeline oder ein Shell-Skript in der CI.

Methode 1 — Browserbasiertes Tool (kein Setup, Privatsphäre zuerst)

Für eine einmalige Konvertierung oder für XML, das Sie lieber nicht in eine beliebige Website einfügen möchten, ist ein Konverter im Browser der schnellste Weg. Fügen Sie XML in den XML zu JSON Konverter ein, und das JSON erscheint sofort: keine Installation, kein Konto, kein Upload. Alles läuft in der JavaScript-Engine Ihres Browsers, sodass die Daten den Rechner nie verlassen.

Dieses letzte Detail ist wichtiger, als es klingt. SOAP-Umschläge tragen WS-Security-Tokens, interne Konfigurationen tragen Verbindungszeichenfolgen, und Exporte tragen Kundendatensätze. Weil nichts übertragen wird, ist das Tool sicher für XML, das Anmeldedaten oder sensible Nutzlasten enthält. Sie können es selbst überprüfen: Öffnen Sie den Netzwerk-Tab und beobachten Sie, wie beim Konvertieren null Anfragen ausgelöst werden.

Methode 2 — JavaScript / Node.js (fast-xml-parser)

In Node ist fast-xml-parser die Standardwahl. Die Voreinstellungen werden Sie allerdings überraschen, denn Attribute werden ignoriert und Werte umgewandelt. Die folgenden Optionen sind die, die Sie für eine getreue Konvertierung tatsächlich wollen:

// XML in JSON in Node.js mit fast-xml-parser konvertieren
import { XMLParser } from 'fast-xml-parser';

const xml = `<catalog>
  <product id="P01">
    <name>Wireless Headphones</name>
    <price currency="USD">79.99</price>
  </product>
</catalog>`;

const parser = new XMLParser({
  ignoreAttributes: false,    // Attribute behalten (Standard verwirft sie!)
  attributeNamePrefix: '@_',  // Attribute werden zu @_-präfixierten Schlüsseln
  textNodeName: '#text',      // Text gemischten Inhalts landet unter #text
  parseAttributeValue: false, // keine Typumwandlung bei Attributen
  parseTagValue: false,       // keine Typumwandlung bei Elementtext
});

const result = parser.parse(xml);
console.log(JSON.stringify(result, null, 2));
// {
//   "catalog": {
//     "product": {
//       "@_id": "P01",
//       "name": "Wireless Headphones",
//       "price": {
//         "@_currency": "USD",
//         "#text": "79.99"
//       }
//     }
//   }
// }

Die beiden Einstellungen, die man vergisst, sind ignoreAttributes: false und parseTagValue: false. Die erste behält Ihre id- und currency-Attribute; die zweite hindert den Parser daran, "79.99" in einen Float und "01234" in 1234 zu verwandeln. Warum die String-Erhaltung die sichere Voreinstellung ist, behandeln wir im Abschnitt über die Fallstricke.

Wenn Sie im Browser keine Abhängigkeiten wollen, übernimmt der native DOMParser das Parsen für Sie, und Sie laufen das DOM selbst ab:

// XML zu JSON ohne Abhängigkeiten im Browser mit DOMParser
function xmlToJson(node) {
  // Element nur mit Text → String-Wert
  const children = Array.from(node.children);
  if (children.length === 0 && node.attributes.length === 0) {
    return node.textContent.trim();
  }

  const obj = {};
  // Attribute → @_-Präfix
  for (const attr of node.attributes) {
    obj['@_' + attr.name] = attr.value;
  }
  // Element mit Attributen UND Text → #text
  if (children.length === 0) {
    obj['#text'] = node.textContent.trim();
    return obj;
  }
  // In Kinder rekursieren, gleichnamige Geschwister in Arrays sammeln
  for (const child of children) {
    const value = xmlToJson(child);
    if (obj[child.tagName] === undefined) {
      obj[child.tagName] = value;
    } else {
      if (!Array.isArray(obj[child.tagName])) obj[child.tagName] = [obj[child.tagName]];
      obj[child.tagName].push(value);
    }
  }
  return obj;
}

const doc = new DOMParser().parseFromString(
  '<catalog><product id="P01"><name>Wireless Headphones</name></product></catalog>',
  'text/xml'
);
const json = { [doc.documentElement.tagName]: xmlToJson(doc.documentElement) };
console.log(JSON.stringify(json, null, 2));
// { "catalog": { "product": { "@_id": "P01", "name": "Wireless Headphones" } } }

DOMParser ist XML-1.0-konform, verarbeitet CDATA und Entity-Referenzen und meldet Wohlgeformtheitsfehler, und das alles ohne die Installation eines Pakets. Der Kompromiss ist, dass Sie die Traversierungslogik selbst verantworten, einschließlich der oben gezeigten Array-Sammelregel.

Methode 3 — Python (xmltodict)

In Python fasst xmltodict die ganze Aufgabe zu einer kurzen Pipeline zusammen. Es verwendet standardmäßig @ als Attributpräfix und #text für gemischten Inhalt:

# XML in JSON in Python mit xmltodict konvertieren
import json
import xmltodict

xml = """<catalog>
  <product id="P01">
    <name>Wireless Headphones</name>
    <price currency="USD">79.99</price>
  </product>
</catalog>"""

data = xmltodict.parse(xml)
print(json.dumps(data, indent=2))
# {
#   "catalog": {
#     "product": {
#       "@id": "P01",
#       "name": "Wireless Headphones",
#       "price": {
#         "@currency": "USD",
#         "#text": "79.99"
#       }
#     }
#   }
# }

Standardmäßig behält xmltodict jeden Wert als String, was das Verhalten ist, das Sie wollen. Die eine Option, die es vorab zu kennen lohnt, ist force_list, die das Problem von Einzahl gegen Mehrzahl beim Array löst, bevor es Ihren Code erreicht:

# force_list garantiert, dass <product> immer eine Liste ist, auch wenn es nur eine gibt
data = xmltodict.parse(xml, force_list={'product'})
products = data['catalog']['product']  # jetzt immer eine Liste
for p in products:
    print(p['name'])

Ohne force_list ergibt ein <product> ein Dict und zwei eine Liste, und Ihre Schleife stürzt im Einzelfall ab. Das ist Fallstrick Nr. 1, den wir weiter unten behandeln.

Methode 4 — CLI (yq / Python-Einzeiler)

Für Shell-Skripte und CI-Pipelines decken zwei Einzeiler die meisten Fälle ab. Mike Farahs yq liest XML und gibt JSON direkt aus:

# Mit yq (Mike Farahs Go-Version)
yq -p=xml -o=json '.' input.xml

# Aus stdin durchleiten
cat sitemap.xml | yq -p=xml -o=json '.'

Wenn xmltodict bereits in Ihrer Umgebung vorhanden ist, braucht der Python-Einzeiler keine zusätzliche Binärdatei:

python3 -c "import sys, xmltodict, json; print(json.dumps(xmltodict.parse(sys.stdin.read()), indent=2))" < input.xml

Beide lesen als Stream aus stdin, sodass sie sich direkt in eine Pipeline einfügen. Das ist nützlich, um eine API-Antwort mitten im Skript zu konvertieren oder einen Stapel von Dateien in einem Build-Schritt zu normalisieren.

Die @_-Attribut- und #text-Konventionen erklärt

Die meisten Konverter-Seiten überspringen den Teil, der wirklich zählt: was die seltsamen @_- und #text-Schlüssel bedeuten und warum es sie gibt. Bringen Sie diese ins Reine, und die Ausgabe hört auf, willkürlich auszusehen.

Attribute werden auf @_-präfixierte Schlüssel abgebildet. Ein Attribut hat kein JSON-Äquivalent — es gibt in einem Objekt keinen Platz für „Metadaten über dieses Objekt”, der sich von einem Kind unterscheidet. Die Konvention besteht darin, Attributen einen mit @_ präfixierten Schlüssel zu geben:

<user id="42" role="admin"/>
→ { "user": { "@_id": "42", "@_role": "admin" } }

Warum gerade @_? Weil kein gültiger XML-Elementname mit @ beginnen kann, kann das Präfix nie mit einem echten Kindelement-Schlüssel kollidieren. Es ist ein reservierter Namespace, der sich in aller Öffentlichkeit versteckt. (xmltodict verwendet ein bloßes @; fast-xml-parser verwendet standardmäßig @_. Das Prinzip ist identisch.)

Gemischter Inhalt wird auf #text abgebildet. Wenn ein Element sowohl ein Attribut als auch einen Textwert hat, braucht der Text einen Platz neben den Attributschlüsseln. Das ist #text:

<price currency="USD">29.99</price>
→ { "price": { "@_currency": "USD", "#text": "29.99" } }

Reine Textelemente werden zu einem direkten String-Wert. Keine Attribute, keine Kinder, nur Text — also besteht kein Bedarf für den Umweg über #text. <name>Alice</name> wird zu "name": "Alice". Der #text-Schlüssel erscheint nur, wenn Attribute erzwingen, dass der Elementwert ein Objekt ist.

Diese Asymmetrie ist die Quelle eines subtilen Fehlers. Derselbe Elementname kann in einem Dokument einen reinen String und in einem anderen ein @_/#text-Objekt erzeugen, je nachdem, ob diese bestimmte Instanz ein Attribut trug. Ein <price> ohne currency-Attribut ist der String "29.99"; dasselbe <price currency="USD"> ist { "@_currency": "USD", "#text": "29.99" }. Code, der node.price direkt liest, funktioniert für die eine Form und bricht stillschweigend bei der anderen. Der defensive Zugriff besteht darin, den Typ zu prüfen: const amount = typeof node.price === 'object' ? node.price['#text'] : node.price;.

CDATA wird zu reinem Textinhalt. Ein <![CDATA[if (a < b) return;]]>-Abschnitt ist nur ein Maskierungsmechanismus, daher werden die Begrenzer entfernt und der innere Text erhalten: "if (a < b) return;". Nichts Besonderes überlebt ins JSON.

Sobald Sie eine Ausgabe haben, fügen Sie sie in einen JSON-Formatierer ein, um die JSON-Ausgabe zu validieren und zu bestätigen, dass die Struktur dem entspricht, was Ihr Konsument erwartet, bevor Sie sie in Code einbinden.

5 XML-zu-JSON-Fallstricke und wie Sie sie vermeiden

Dies sind die Fehler, die das Code-Review passieren und in der Produktion auftauchen. Jeder einzelne lässt sich auf die Modelldiskrepanz vom Anfang dieses Leitfadens zurückführen.

1. Array-Mehrdeutigkeit (eins gegen viele). Ein einzelnes <item> wird zu einem Objekt; zwei oder mehr werden zu einem Array. Die JSON-Form hängt davon ab, wie viele Geschwister sich zufällig in diesem bestimmten Dokument befanden. Konsumentencode wie result.items.item.forEach(...) funktioniert im Test — wo Ihre Vorlage drei Items hat — und wirft in der Produktion TypeError: not a function, wenn ein Datensatz genau eines hat.

// Zwei <book>-Geschwister → Array
// <library><book>A</book><book>B</book></library>
// → { "library": { "book": ["A", "B"] } }

// Ein <book> → Objekt, KEIN Array
// <library><book>A</book></library>
// → { "library": { "book": "A" } }

// Normalisieren, damit sich beide Fälle identisch verhalten
const books = [].concat(result.library?.book ?? []);
books.forEach(b => console.log(b)); // sicher für 0, 1 oder viele

Die Redewendung [].concat(x ?? []) ist es wert, sich gemerkt zu werden: Ein fehlender Wert wird zu [], ein einzelnes Objekt wird zu [object], und ein bestehendes Array geht unverändert hindurch. In Python übergeben Sie force_list={'book'} an xmltodict.parse(), und der Wert ist immer eine Liste, sodass Sie die Normalisierung ganz überspringen.

2. Still verworfene Attribute. Mehrere Bibliotheken ignorieren standardmäßig Attribute — fast-xml-parser macht genau das, bis Sie ignoreAttributes: false setzen. Die Konvertierung sieht aus, als hätte sie funktioniert, das JSON parst einwandfrei, und Ihre id-, currency- und status-Werte sind einfach weg. Setzen Sie das Flag immer ausdrücklich, statt der Voreinstellung zu vertrauen.

3. Namespace-Abflachung. Eine xmlns-Deklaration wird zu einem gewöhnlichen @_xmlns-Schlüssel, und das Präfix in <soap:Body> überlebt nur als Teil des String-Schlüssels "soap:Body". Die Semantik — dass zwei Präfixe an dieselbe URI gebunden sein könnten — geht verloren.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>...</soap:Body>
</soap:Envelope>
→ {
    "soap:Envelope": {
      "@_xmlns:soap": "http://schemas.xmlsoap.org/soap/envelope/",
      "soap:Body": "..."
    }
  }

Das Präfix soap: ist jetzt nur noch Text in einem Schlüsselnamen; nichts weiß, dass es ein Namespace ist. Wenn zwei Elemente aus verschiedenen Namespaces einen lokalen Namen teilen, können sie kollidieren. Wenn präzise Namespace-Behandlung Teil der Anforderung ist, halten Sie die Daten in einem namespace-fähigen Parser und flachen Sie sie gar nicht erst ins JSON ab.

4. Keine Typumwandlung — und das ist richtig so. <zip>01234</zip> darf nicht zu 1234 werden. Kontocodes, Postleitzahlen, aufgefüllte Bezeichner und präzisionsempfindliche Dezimalzahlen brechen alle unter stiller Umwandlung. Ein guter Konverter behält alles als String und lässt Sie bewusst umwandeln:

// Verlassen Sie sich nicht auf implizite Umwandlung
if (config.timeout > 25) { /* fragil: "30" > 25 funktioniert zufällig */ }

// Wandeln Sie ausdrücklich um, nur wo Sie den Typ kennen
if (parseInt(config.timeout, 10) > 25) { /* sicher */ }

5. Verlustbehaftet: Kommentare, Verarbeitungsanweisungen und Reihenfolge gemischten Inhalts. XML-Kommentare () und Verarbeitungsanweisungen (<?xml-stylesheet ?>) haben kein JSON-Zuhause und werden verworfen. Die relative Reihenfolge von Text, der mit Kindelementen verschachtelt ist, übersteht den Hin- und Rückweg möglicherweise nicht. Wenn Sie jedes Byte erhalten müssen, etwa um das exakte Quelldokument erneut auszugeben, konvertieren Sie überhaupt nicht; verwenden Sie einen XML-Formatierer, um neu zu formatieren oder zu minimieren, ohne das Datenmodell anzutasten.

JSON wieder in XML konvertieren (Hin- und Rückweg)

Die andere Richtung hat ihren eigenen Haken, denn JSON hat keine Regel für ein Wurzelelement, und XML verlangt genau eines. Der zugehörige JSON zu XML Konverter wendet dieselben @_-/#text-Konventionen umgekehrt an, sodass ein Hin- und Rückweg JSON → XML → JSON Attribute, Text und Struktur bewahrt.

Der interessante Teil ist die Wurzelnormalisierung. Der Konverter löst die Anforderung der einzelnen Wurzel mit vier Regeln:

Objekt mit einem Schlüssel → dieser Schlüssel wird zur Wurzel: { "config": {...} } → <config>...</config>.
Objekt mit mehreren Schlüsseln → in <root> gewickelt: { "a": 1, "b": 2 } → <root><a>1</a><b>2</b></root>.
Array auf oberster Ebene → als <root><item>...</item></root> gewickelt, mit <item> als festem Ersatznamen.
Primitiver Wert → <root>value</root>.

Alles andere spiegelt die Vorwärtsrichtung. @_-Schlüssel werden zu Attributen, #text wird zu Textinhalt, und ein JSON-Array unter einem Schlüssel erzeugt wiederholte gleichnamige Geschwister, wobei der Schlüsselname wiederverwendet und nie in den Singular gesetzt wird:

// JSON in XML in Node.js mit fast-xml-parser konvertieren
import { XMLBuilder } from 'fast-xml-parser';

const data = {
  catalog: {
    product: {
      '@_id': 'P01',
      name: 'Wireless Headphones',
      price: { '@_currency': 'USD', '#text': '79.99' },
    },
  },
};

const builder = new XMLBuilder({
  attributeNamePrefix: '@_', // @_-Schlüssel werden zu Attributen
  textNodeName: '#text',     // #text-Schlüssel wird zu Textinhalt
  ignoreAttributes: false,   // @_-Schlüssel verarbeiten
  format: true,              // hübsch formatieren
});

console.log(builder.build(data));
// <catalog>
//   <product id="P01">
//     <name>Wireless Headphones</name>
//     <price currency="USD">79.99</price>
//   </product>
// </catalog>

Ein Detail, das der Builder für Sie erledigt: Sonderzeichen in Text- und Attributwerten (<, >, &, ") werden zu ihren Entity-Referenzen maskiert, sodass die Ausgabe wohlgeformt bleibt.

FAQ

Wie werden XML-Attribute auf JSON abgebildet?

Attribute werden zu Schlüsseln, die mit @_ präfixiert sind, sodass id="42" zu "@_id": "42" wird. Dies ist die gemeinsame Konvention von fast-xml-parser und xmltodict, und das Präfix kollidiert nie mit Elementnamen, weil kein gültiger Elementname mit @ beginnt.

Warum behält XML zu JSON Zahlen als Strings?

Weil der Konverter keine Typumwandlung vornimmt. 01234 in 1234 zu zwingen würde eine bedeutungsvolle führende Null aus Postleitzahlen, Kontonummern und aufgefüllten IDs entfernen. Jeden Wert als String zu behalten ist die sichere Voreinstellung; wandeln Sie bewusst nachgelagert um, wo Sie den Typ kennen.

Ist die XML-zu-JSON-Konvertierung verlustfrei?

Nein. Kommentare und Verarbeitungsanweisungen werden verworfen, die Namespace-Semantik bleibt nur teilweise erhalten, und die Reihenfolge gemischten Inhalts übersteht den Rückweg möglicherweise nicht. Wenn Sie jedes Byte erhalten müssen, verwenden Sie einen XML-Formatierer, um das XML neu zu formatieren, statt es in JSON zu konvertieren.

Wie werden wiederholte XML-Elemente in JSON behandelt?

Ein einzelnes gleichnamiges Kind wird zu einem Objekt; zwei oder mehr werden zu einem Array. Weil die Form von der Anzahl der Geschwister abhängt, sollte Ihr Konsumentencode immer auf ein Array normalisieren, damit er sowohl den Ein-Item- als auch den Viele-Item-Fall ohne Absturz behandelt.

Was passiert mit XML-Namespaces bei der Konvertierung zu JSON?

Eine xmlns-Deklaration wird zu einem gewöhnlichen @_xmlns-Schlüssel, und das Präfix bleibt im Elementnamen-String, wie in "soap:Body". Die semantische Bindung eines Präfixes an eine URI wird nicht interpretiert, sodass verschiedene Namespaces zusammenfließen können.

Wie konvertiere ich JSON wieder in XML?

Verwenden Sie den zugehörigen JSON zu XML Konverter. Er wendet dieselben @_- und #text-Konventionen umgekehrt an, sodass Attribute, Textinhalt und Arrays symmetrisch zurückgebildet werden. Diese Symmetrie ist es, die einen sauberen Hin- und Rückweg JSON → XML → JSON möglich macht.

Kann ich XML mit mehreren Wurzelelementen konvertieren?

Nein. Mehrere Elemente auf oberster Ebene sind kein wohlgeformtes XML, daher weist der Parser die Eingabe ab. Wickeln Sie die Fragmente zuerst in ein einzelnes Wurzelelement — verwandeln Sie <a/><b/> in <root><a/><b/></root> — und konvertieren Sie dann.

Fazit

Die XML-zu-JSON-Konvertierung ist konventionsgesteuert, keine Umformatierung. Die Regeln sind über alle Laufzeitumgebungen hinweg konsistent: Attribute werden auf @_-Schlüssel abgebildet, der Text gemischten Inhalts auf #text, wiederholte Geschwister auf Arrays, und Werte bleiben Strings, sodass führende Nullen und Präzision überleben. Die Fallen, die man sich merken sollte, sind der Formwechsel zwischen Einzahl und Array, still verworfene Attribute und der Verlust von Kommentaren und Namespace-Semantik. Keine davon sind Fehler, und alle sind vorhersehbar, sobald Sie die dahinterliegende Modelldiskrepanz kennen.

Wenn Sie eine schnelle, private Konvertierung brauchen, fügen Sie sie in den XML zu JSON Konverter ein; er läuft vollständig in Ihrem Browser. Validieren Sie die Quelle zuerst mit dem XML-Formatierer, und gehen Sie mit dem JSON zu XML Konverter die andere Richtung, wenn Sie XML im Hin- und Rückweg brauchen. Mehr dazu, wie die Modelle von Datenformaten das Konvertierungsverhalten prägen, finden Sie in den Notizen zu den Unterschieden zwischen YAML und JSON.

XML zu JSON: Konventionen, Fallstricke und Codebeispiele