Wenn du schon mal eine ältere Enterprise-API integriert oder mit RSS-Feeds gearbeitet hast, bist du XML begegnet. Wenn du irgendetwas im modernen Web gebaut hast, lebst du in JSON. Beide Formate lösen dasselbe Kernproblem — strukturierte Daten als Text darzustellen — aber auf sehr unterschiedliche Weise. Dieser Artikel schlüsselt die echten Unterschiede auf, damit du eine fundierte Entscheidung treffen kannst.

Dieselben Daten, zwei Formate

Fangen wir mit einem konkreten Beispiel an. Hier ist ein User-Objekt in JSON:

json
{
  "user": {
    "id": 101,
    "name": "Bob",
    "email": "[email protected]",
    "roles": ["admin", "editor"],
    "active": true
  }
}

Und hier sind exakt dieselben Daten in XML:

xml
<?xml version="1.0" encoding="UTF-8"?>
<user>
  <id>101</id>
  <name>Bob</name>
  <email>[email protected]</email>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
  <active>true</active>
</user>

Die JSON-Version hat 62 Zeichen. Die XML-Version hat 198 Zeichen — 3× größer für dieselben Daten. Bei einem kleinen Payload macht das nichts aus. Bei einer High-Traffic-API, die Millionen Requests pro Tag bedient, summiert sich die Bandbreite schnell.

Wo JSON gewinnt

  • Kompaktheit. Keine schließenden Tags. Weniger Wiederholungen. Kleinere Payloads auf der Leitung.
  • Nativer JavaScript-Support. JSON.parse() und JSON.stringify() sind in jede JS-Runtime eingebaut. Keine externe Library nötig.
  • Einfachheit. Sechs Datentypen und ein paar Regeln. Du kannst die gesamte JSON-Spec in 10 Minuten lesen.
  • Array-Support. JSON hat native Arrays. In XML bist du darauf angewiesen, Elemente wie <role> <role> <role> zu wiederholen.
  • Tooling. Moderne Datenbanken wie PostgreSQL, MongoDB und MySQL haben erstklassigen JSON-Support. Die meisten Logging-Plattformen parsen JSON nativ.
  • Lesbarkeit. Entwickler finden JSON einfacher zu scannen. Weniger Lärm durch spitze Klammern und schließende Tags.

Wo XML noch gewinnt

  • Attribute und Metadaten. XML-Elemente können Attribute tragen: <user id="101" active="true">. Nützlich, wenn du Daten annotieren willst, ohne Kind-Elemente hinzuzufügen.
  • Namespaces. XML-Namespaces lassen dich Vokabulare in einem Dokument mischen — kritisch in Formaten wie XHTML, SVG, SOAP und Office Open XML.
  • Schema-Validierung. XML Schema (XSD) bietet mächtige, standardisierte Validierung einschließlich Datentypen, Mustern und Kardinalität. JSON Schema holt auf, aber XML Schema hat Jahrzehnte an Tooling dahinter.
  • Dokumentenzentrierte Anwendungsfälle. XML wurde für Dokumente entworfen, nicht nur Daten. Formate wie XHTML, DocBook und DITA basieren auf XML und eignen sich hervorragend für Inhalte mit gemischtem Text und Markup.
  • XSLT-Transformationen. Du kannst XML mit XSLT in HTML, anderes XML oder Plaintext transformieren — ein mächtiges Tool für Publishing-Pipelines.
  • Kommentare. XML unterstützt Kommentare. JSON nicht. Für Config-Dateien, wo du erklären willst, warum eine Einstellung existiert, macht das einen Unterschied.

Performance: Spielt das wirklich eine Rolle?

Für die meisten Anwendungen ist der Unterschied in der Parse-Performance zwischen JSON und XML irrelevant. Wo es darauf ankommt — hochfrequente Daten-Feeds, IoT-Telemetrie, Echtzeitsysteme — gewinnt JSON klar. JSON-Parser sind einfacher und schneller, weil das Format selbst einfacher ist. Ein schneller Benchmark: Das Parsen einer 1MB-JSON-Datei in Node.js dauert typischerweise 10–30ms. Das äquivalente XML mit einem SAX-Parser ist oft 2–5× langsamer, mit einem DOM-Parser noch schlechter.

Wenn Performance wirklich kritisch ist, ist keines der Formate ideal — du würdest zu einem Binärformat wie Protocol Buffers oder MessagePack greifen. Aber für typische Web-API-Arbeit ist die Performance von JSON mehr als ausreichend.

Entscheidungsleitfaden: Wann welches Format?

Nimm JSON wenn:

  • Du REST- oder GraphQL-APIs baust
  • Du Konfiguration oder Einstellungen speicherst (package.json, tsconfig.json, etc.)
  • Du mit JavaScript, TypeScript, Python, Ruby, Go arbeitest — jeder modernen Sprache
  • Du mit einer modernen Drittanbieter-API kommunizierst
  • Du Dokumente in MongoDB, Elasticsearch oder PostgreSQL-JSONB-Spalten speicherst

Nimm XML wenn:

  • Du mit Legacy-Enterprise-Systemen integrierst (SAP, Salesforce SOAP APIs, etc.)
  • Du mit Dokumentformaten arbeitest: SVG, EPUB, Office Open XML (.docx, .xlsx)
  • Publishing-Pipelines XSLT-Transformationen verwenden
  • RSS / Atom-Feeds
  • Du Daten in Branchen mit etablierten XML-Standards austauschst (HL7 im Gesundheitswesen, FpML in der Finanzwelt, etc.)
Die ehrliche Antwort: Wenn du ein Greenfield-Projekt startest und kein externes System XML oder JSON vorschreibt, wähle JSON. Es wird deinem Team jede Woche Zeit sparen. XML ist die richtige Wahl, wenn du in einem Ökosystem arbeitest, das bereits XML-basiert ist.

Mit beiden Formaten arbeiten

Manchmal musst du zwischen den beiden konvertieren. Vielleicht konsumierst du eine XML-Legacy-API und willst die Daten als JSON speichern, oder du musst Daten von einem JSON-nativen Backend an einen XML-basierten Service senden. Du kannst den XML-zu-JSON-Konverter oder den JSON-zu-XML-Konverter für diese Transformationen nutzen. Zum Inspizieren von XML-Antworten sind XML Formatter und XML Validator praktisch.

Fazit

JSON und XML lösen dasselbe Problem, aber dienen unterschiedlichen Kontexten. JSON ist die richtige Wahl für die überwiegende Mehrheit der modernen Entwicklung — es ist einfacher, kleiner und hat besseren nativen Support in jeder Sprache. XML hat echte einzigartige Stärken in dokumentenzentrierten und namespace-bewussten Anwendungsfällen. Die gute Nachricht ist, dass du nicht dogmatisch sein musst — beide Formate sind ausgereift, gut unterstützt und werden noch lange koexistieren. Kenn die Tradeoffs und wähle das richtige Tool für die Aufgabe.

← All JSON articles Browse all categories →