XML online formatieren und prüfen

So formatieren Sie XML

1. Fügen Sie Ihr XML in das Feld ein – eine XRechnung oder die XML-Datei aus einer ZUGFeRD-Rechnung, eine SOAP-Nachricht, einen RSS-Feed, eine Sitemap, eine Maven-pom.xml oder eine SVG-Datei. Es wird schon beim Einfügen geprüft und formatiert.
2. Wählen Sie Formatieren, damit jedes Element in einer eigenen Zeile steht, eingerückt mit 2 oder 4 Leerzeichen oder einem Tab, oder Minifizieren, um die Leerräume zwischen den Tags zu entfernen.
3. Tippen Sie auf Kopieren oder auf Herunterladen, um das Ergebnis als Datei zu speichern.
4. Ist das XML nicht wohlgeformt, sehen Sie den Fehler, Zeile und Spalte, die Zeile selbst mit einem ^ unter der Stelle und die Lösung. Sobald Sie ihn behoben haben, erscheint das formatierte XML.

Was der Formatierer ändert – und was nie

Ein XML-Dokument ist ein Baum aus Elementen. Beim Formatieren kommt jedes Kindelement, jeder Kommentar und jede Verarbeitungsanweisung in eine eigene Zeile, eingerückt nach Verschachtelungstiefe; Minifizieren entfernt diese Umbrüche wieder. Das geschieht nur in Elementen, die ausschließlich andere Elemente enthalten, denn nur dort sind Leerräume zwischen Tags bedeutungslos. Alles andere wird Zeichen für Zeichen übernommen:

• Textinhalt, auch Leerzeichen am Anfang oder Ende: <name> Lena </name> behält beide Leerzeichenpaare.
• Gemischter Inhalt – Text und Tags in einem Element, wie <hinweis>Lieferung <b>bis Freitag</b>.</hinweis> – bleibt genau so, denn ein Zeilenumbruch würde dort Teil des Textes.
• Elemente mit xml:space="preserve" samt ihrem gesamten Inhalt.
• CDATA-Abschnitte, Kommentare, Verarbeitungsanweisungen und der DOCTYPE.
• Entitäts- und Zeichenreferenzen: & bleibt &, und ä wird nicht zu ä.
• Attributwerte, ihre Anführungszeichen und ihre Reihenfolge. Im Tag selbst wird aufgeräumt: ein Leerzeichen vor jedem Attribut und keines um das =.

Windows-Zeilenumbrüche (CR LF) werden als LF geschrieben, wie jeder XML-Parser sie ohnehin liest.

Was „wohlgeformt“ bedeutet

Jede XML-Datei muss die Syntaxregeln von XML 1.0 und der Namensräume in XML einhalten, sonst liest sie kein Programm. Der Prüfer meldet die erste verletzte Regel: genau ein Wurzelelement; jedes Start-Tag mit passendem End-Tag in der richtigen Reihenfolge und gleicher Schreibweise; Attributwerte in Anführungszeichen und kein Attribut doppelt; & und < im Text als & und <; nur die fünf vordefinierten Entitäten, sofern kein DOCTYPE weitere deklariert; jedes Präfix wie cbc: mit xmlns:cbc="…" deklariert; die Deklaration <?xml … ?> ganz am Anfang. Ein Beispiel:

  <name>Müller & Söhne GmbH</name>
               ^

Das ergibt Nicht maskiertes & in Zeile 2, Spalte 16: Das kaufmännische Und im Firmennamen muss Müller & Söhne GmbH heißen. Das ist der häufigste Fehler in von Hand oder per Skript erzeugten Rechnungen und Produktfeeds.

Wohlgeformt ist nicht dasselbe wie gültig. Die Gültigkeitsprüfung vergleicht ein Dokument mit einem Schema (XSD, DTD, bei E-Rechnungen zusätzlich Schematron-Regeln), das festlegt, welche Elemente und Werte erlaubt sind. Diese Seite prüft die Syntax, nicht das Schema.

Beispiel

Im Feld steht eine 477 Byte lange Bestellung in einer einzigen Zeile, mit Namensraum, Kommentar, gemischtem Inhalt und CDATA-Abschnitt. Mit 2 Leerzeichen formatiert sieht sie so aus:

<?xml version="1.0" encoding="UTF-8"?>
<bestellung nr="2026-1016" xmlns:adr="urn:beispiel:adresse">
  <!-- Testdaten -->
  <kunde>
    <adr:name>Müller &amp; Söhne GmbH</adr:name>
    <adr:ort plz="01067">Dresden</adr:ort>
  </kunde>
  <position nr="1">
    <artikel>Röstkaffee 500 g</artikel>
    <menge einheit="Stück">2</menge>
    <preis waehrung="EUR">12.50</preis>
  </position>
  <hinweis>Lieferung <b>bis Freitag</b>.</hinweis>
  <bemerkung><![CDATA[Preis < 50 € & versandkostenfrei]]></bemerkung>
</bestellung>

Die 11 Elemente sind 3 Ebenen tief verschachtelt. <hinweis> mischt Text und ein Tag und bleibt deshalb in einer Zeile; der CDATA-Abschnitt behält sein unmaskiertes < und &. Das Einrücken fügt 48 Bytes hinzu; minifiziert ist die Datei wieder 477 Bytes groß. Umlaute und das €-Zeichen zählen in UTF-8 als zwei beziehungsweise drei Bytes.

E-Rechnungen: XRechnung und ZUGFeRD lesbar machen

Seit dem 1. Januar 2025 müssen Unternehmen in Deutschland E-Rechnungen von anderen Unternehmen empfangen können. Eine E-Rechnung im Sinne des Gesetzes folgt der europäischen Norm EN 16931 – in der Praxis eine XRechnung, also reines XML, oder eine ZUGFeRD-Rechnung ab dem Profil EN 16931, bei der die XML-Datei in ein PDF/A-3 eingebettet ist. Ein PDF ohne diese XML-Daten ist keine E-Rechnung. Wer eine XRechnung zum ersten Mal öffnet, sieht oft eine einzige endlose Zeile; formatiert wird sie lesbar.

XRechnung gibt es in zwei Syntaxen: UBL 2.1 (Wurzelelement Invoice) und UN/CEFACT CII (Wurzelelement rsm:CrossIndustryInvoice), die ZUGFeRD verwendet. Ein Ausschnitt aus dem Kopf einer UBL-Rechnung – kein vollständiges Dokument – sieht formatiert so aus:

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:ID>RE-2026-1016</cbc:ID>
  <cbc:IssueDate>2026-10-16</cbc:IssueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
</Invoice>

cbc: ist das Präfix der „Common Basic Components“, und der Rechnungsartcode 380 steht für eine Handelsrechnung. Bei Rechnungen an Behörden kommt die Leitweg-ID des Empfängers hinzu. Ob eine Rechnung alle Regeln von XRechnung erfüllt, prüft dieser Formatierer nicht: Dafür gibt es den Validator der Koordinierungsstelle für IT-Standards (KoSIT), der Schema und Schematron-Regeln anwendet. Ein Fehler wie „Namensraum-Präfix nicht deklariert“ hier bedeutet aber sicher, dass auch jeder Validator die Datei ablehnt.

Wichtig: Formatieren Sie eine Kopie. Eingehende E-Rechnungen sind im Original aufzubewahren, und eine nachträglich umformatierte Datei ist nicht mehr das Original. Bei signierten Dokumenten (SOAP mit XML-Signatur, SAML) deckt die Signatur den exakten Text samt Leerräumen ab, sodass eine formatierte Kopie die Signaturprüfung nicht mehr besteht.

Grenzen und Tipps

• Große Dateien: Eine Rechnung von 200 KB mit Tausenden Elementen wird in deutlich unter einer Sekunde geprüft und formatiert, und lange Ergebnisse scrollen flüssig. Dateien von zig Megabyte sind in einem Desktop-Editor bequemer.
• Zeichenkodierung: Die Seite arbeitet mit den eingefügten Zeichen, Herunterladen speichert UTF-8. Steht in der Deklaration encoding="ISO-8859-1" oder windows-1252, ändern Sie das in der heruntergeladenen Datei auf UTF-8, sonst werden Umlaute falsch gelesen.
• DTD-Entitäten: Hat ein Dokument einen DOCTYPE, werden benannte Entitäten akzeptiert, ohne zu prüfen, ob die DTD sie deklariert.
• HTML ist kein XML. Tags wie <br> ohne schließenden Schrägstrich sind hier Fehler. Für JSON nutzen Sie den JSON-Formatierer, und Tabellen aus JSON erzeugt JSON in CSV umwandeln.

Parsen, Prüfen und Formatieren laufen vollständig in Ihrem Browser. Rechnungen und API-Nachrichten enthalten Steuernummern, Bankverbindungen, Adressen und Preise; nichts davon wird hochgeladen, protokolliert oder gespeichert – nach dem Neuladen ist das Feld leer.

Häufige Fragen

Zuletzt aktualisiert: 16. Oktober 2026