XML-Formatierer und -Validator
Formatieren, validieren oder verkleinern Sie XML sofort im Browser — das Ergebnis aktualisiert sich live.
Ihr Dokument bleibt auf Ihrem Gerät
Nichts, das später zu löschen wäre
Sicher für regulierte Dokumente
Läuft in jedem modernen Browser
So funktioniert es
- 1
Fügen Sie Ihr XML ein
Eine Konfigurationsdatei, eine API-Antwort, eine Rechnung, einen Feed oder einen Export, den Sie lesen müssen.
- 2
Formatieren oder minifizieren
Rücken Sie es zum Lesen ein oder verdichten Sie es wieder — die Warnungen erscheinen in beiden Fällen.
- 3
Kopieren Sie das Ergebnis
Nehmen Sie es in einen Editor, ein Ticket, eine Testvorlage oder ein Dokument mit, das Sie versenden.
Warum dieses Tool
Hinweis, wenn Formatieren Daten ändert
Ein Element mit Text einzurücken verändert diesen Text, und Sie erfahren es vorher statt hinterher.
Namensraum-Präfixe bleiben erhalten
Präfixe bleiben genau so, wie sie geschrieben wurden, damit XPath-Ausdrücke und Stylesheets weiter funktionieren.
Externe Entitäten werden nie aufgelöst
Keine Datei wird gelesen, keine URL abgerufen — die wichtigste Eigenschaft, die ein XML-Werkzeug haben kann.
Expansionsbomben werden abgelehnt
Ein kleines Dokument, das sich zu Gigabyte aufbläht, wird erkannt und zurückgewiesen, statt den Tab einzufrieren.
Deklaration und Kodierung bleiben
Die XML-Deklaration, ihr Kodierungsattribut und eine etwaige Bytereihenfolge-Markierung überstehen den Weg unverändert.
Nichts verlässt den Browser
Rechnungen, SOAP-Nachrichten und Identitätsbestätigungen werden auf dieser Seite verarbeitet und nirgends hochgeladen.
XML einzurücken ist nicht kosmetisch — Leerraum in einem Element sind Daten
Das ist die Tatsache, die XML-Formatierung von JSON-Formatierung trennt, und fast jede Überraschung in diesem Thema folgt daraus. In JSON liegt der Leerraum zwischen den Tokens vollständig außerhalb des Datenmodells: Formatieren Sie ein Dokument neu, und jeder Wert, den Ihr Parser liest, bleibt derselbe. XML gibt diese Garantie nicht. Der Inhalt eines Elements ist ein Textknoten, und Leerraum gehört zu diesem Knoten, sofern nicht etwas ausdrücklich anderes sagt. Verwandeln Sie `<name>Ali</name>` in eine eingerückte Form mit dem Text in einer eigenen Zeile, und das Element enthält nicht mehr `Ali` — es enthält einen Zeilenumbruch, zwei Leerzeichen, `Ali`, einen weiteren Umbruch und weitere Leerzeichen. Der meiste Anwendungscode verdeckt das, indem er beim Auslesen trimmt, und genau deshalb fällt es erst auf, wenn es zählt: bei einem Wert, der gegen eine Datenbank verglichen wird, einer Prüfsumme, einer Signatur. Die XML-Spezifikation bietet zwar `xml:space="preserve"`, um Leerraum für bedeutsam zu erklären, und ein Schema kann ein Element als leerraumunempfindlich kennzeichnen — aber ein Formatierer, der nur das Dokument sieht, weiß von beidem nichts. Er muss warnen statt annehmen, und genau das tut dieser.
Ein signiertes Dokument neu zu formatieren macht die Signatur ungültig, und zwar absichtlich
Die obige Folge wird in dem Moment konkret, in dem ein Dokument signiert ist. Digitale XML-Signaturen signieren nicht die Datei — sie signieren eine kanonische Form des Dokumentbaums, erzeugt von einem Normalisierungsschritt aus der Spezifikation Canonical XML. Dieser Schritt legt Attributreihenfolge, Namensraumdeklarationen und bestimmten Leerraum fest, damit zwei Dokumente, die dasselbe bedeuten, denselben Hashwert ergeben. Was er nicht tut, ist Leerraum zu verzeihen, den Sie innerhalb des Inhalts eines Elements hinzugefügt haben, denn für das Modell ist das keine Formatierung, sondern eine Änderung der Daten. Eine signierte Rechnung, eine SAML-Bestätigung oder eine SOAP-Nachricht, die verschönert wurde, ist also nicht mehr gültig, und das Versagen ist vollständig: Die Prüfung meldet keine kleine Abweichung, sie meldet, dass die Signatur nicht passt. Die Regel zum Mitnehmen lautet: Ein signiertes Dokument ist ein Binärobjekt im Textkostüm. Lesen Sie es formatiert, wenn Sie mögen, aber senden Sie die Bytes, die Sie erhalten haben.
Deutsche E-Rechnung: der Fall, in dem all das gesetzlich zählt
Es gibt kaum ein Land, in dem dieses Thema so unmittelbar praktisch ist wie hier. Die deutsche elektronische Rechnungsstellung beruht auf XML: XRechnung ist reines XML, ZUGFeRD und das eng verwandte europäische Factur-X betten dieselbe strukturierte Rechnung als XML-Anhang in eine PDF/A-3-Datei ein. Das ergibt eine Datei mit zwei Wahrheiten — der PDF, die Menschen ansehen, und dem XML, das die Buchhaltungssoftware der Gegenseite tatsächlich auswertet. Wer eine abgelehnte Rechnung untersucht, holt sich fast immer das XML heraus und formatiert es, um es überhaupt lesen zu können, und genau dort greifen die beiden vorigen Abschnitte. Erstens: Einrückung, die in einen Elementinhalt gerät, verändert Werte, die eine Prüfregel gegen ein Format oder gegen eine Summe testet. Zweitens: Ist die Rechnung signiert, macht Verschönern sie ungültig, und die Ablehnung kommt zurück, ohne zu sagen warum. Deshalb ist das Muster hier immer dasselbe — formatiert lesen, unverändert senden. Und drittens ist eine Rechnung ein Dokument mit Steuernummer, Bankverbindung und Kundenanschrift, was den Grund liefert, sie nicht auf einen fremden Server zu laden.
Das Namensraum-Präfix ist nicht der Name — die URI ist es
Namensräume sind die Stelle, an der XMLs Entwurf Menschen aus der JSON-Welt am häufigsten überrascht und an der ein achtloser Formatierer echten Schaden anrichtet. Ein Präfix wie `soap:` oder `ns2:` ist eine lokale Abkürzung ohne eigene Bedeutung; was ein Element identifiziert, ist die URI, an die dieses Präfix gebunden ist. Zwei Dokumente mit `a:Body` und `env:Body` sind identisch, wenn beide Präfixe an dieselbe Namensraum-URI gebunden sind, und zwei Dokumente mit jeweils `ns:Item` haben nichts miteinander zu tun, wenn die URIs verschieden sind. Deshalb erzeugt ein Werkzeug, das Präfixe hilfsbereit in etwas Ordentlicheres umbenennt, ein Dokument, das technisch gleichwertig und praktisch kaputt ist: Jeder XPath-Ausdruck, jedes XSLT-Template und jeder handgeschriebene Selektor in Ihrer Codebasis verweist auf das Präfix, nicht auf die URI, weil Menschen genau das schreiben. Standard-Namensräume fügen eine zweite Falle hinzu, denn ein präfixloses Element innerhalb von `xmlns="…"` liegt in diesem Namensraum, während ein präfixloses Attribut in gar keinem liegt. Dieses Werkzeug ändert kein Präfix und verschiebt keine Deklaration.
Entitätsexpansion ist der Grund, warum man einem XML-Parser sagen muss, was er nicht tun soll
XML erlaubt einem Dokument, eigene Entitäten zu definieren, und erlaubt einer Entität, auf eine andere zu verweisen. Diese eine Eigenschaft erzeugt den bekanntesten Denial-of-Service in der Geschichte des Formats: Definieren Sie eine Entität als zehn Kopien einer anderen, verschachteln Sie das zehnfach, und ein Dokument von wenigen hundert Byte bläht sich auf eine Milliarde Zeichen auf. Es hat einen Namen — der Billion-Laughs-Angriff — und es funktioniert bei jedem Parser, der Entitäten ohne Budget expandiert. Das schärfere Problem sind externe Entitäten, mit denen ein Dokument erklären kann, dass der Wert einer Entität von irgendwoher gelesen werden soll: `SYSTEM "file:///etc/passwd"` liest eine lokale Datei, und eine `http://`-URL macht aus dem Parser einen Anfrage-Client, der bereitwillig für einen Angreifer in ein privates Netz greift. Das ist XXE, und damit werden seit Jahren Zugangsdaten von Produktionsservern gelesen. Die Abwehr ist kein cleveres Parsen, sondern Verweigerung: Ein Dokumentverarbeiter, der nie eine externe Entität auflöst, lässt sich zu keinem Abruf bewegen. Dieses Werkzeug löst keine auf und deckelt die Expansion — deshalb wird ein feindliches Dokument hier lediglich abgelehnt.
Was tatsächlich in dem XML steckt, das formatiert werden muss
Es lohnt sich, die Dokumente zu benennen, denn die Liste erklärt die Vorsicht. XML ist der Ort, an dem die regulierten Teile der Softwarewelt leben: elektronische Rechnungen an eine Finanzbehörde, SOAP-Nachrichten zwischen Banken, SAML-Bestätigungen, die buchstäblich die Identität eines Menschen unterwegs sind, Gesundheitsakten, Gerichtsschriftsätze, Lohnexporte, Produktfeeds mit unveröffentlichten Preisen. Wenn jemand zu einem Formatierer greift, dann fast immer, weil eines dieser Dokumente gescheitert ist und gelesen werden muss — das Beispiel in der Zwischenablage ist also ein echtes, mitsamt Steuernummer der Kundin und Subjekt der Bestätigung. Es in einen gehosteten Formatierer zu kleben, lädt genau das hoch, und eine SAML-Bestätigung ist, solange sie gültig ist, ein Inhaberausweis. Diese Seite parst und druckt das Dokument in JavaScript und stellt dabei keine einzige Anfrage; das Netzwerk-Panel Ihrer Entwicklerwerkzeuge zeigt dasselbe.
Häufige Fehler, die Sie vermeiden sollten
- Annehmen, XML-Formatierung sei so sicher wie JSON-Formatierung. Leerraum in einem Element gehört zu dessen Textknoten, Einrücken ändert also die Werte, die ein Parser zurückliest.
- Ein signiertes Dokument verschönern. Signaturen decken eine kanonische Form des Baums ab, und Leerraum im Elementinhalt ist eine Datenänderung — die Prüfung schlägt vollständig fehl.
- Eine signierte E-Rechnung vor dem Versand neu einrücken. XRechnung und ZUGFeRD werden maschinell geprüft, und die Ablehnung sagt Ihnen nicht, dass Ihr Formatierer die Ursache war.
- Ein Werkzeug Namensraum-Präfixe umbenennen lassen. Die URI ist die Identität, aber jedes XPath und XSLT in Ihrer Codebasis verweist auf das Präfix.
- Nicht vertrauenswürdiges XML mit aktivierten externen Entitäten parsen. `SYSTEM "file:///…"` liest lokale Dateien, und eine http-URL lässt den Parser für einen Angreifer abrufen — das ist XXE.
Im Vergleich
| Aspekt | Dieses Werkzeug | Online-Formatierer | Ein Editor-Plugin |
|---|---|---|---|
| Dokument an einen Server gesendet | Nie | Meistens ja | Nein |
| Warnt, wenn Einrücken Daten ändert | Ja | Nein | Selten |
| Löst externe Entitäten auf | Nie | Manchmal | Konfigurierbar |
| Erhält Namensraum-Präfixe | Immer | Meistens | Meistens |
| Behält Deklaration und BOM | Ja | Unterschiedlich | Meistens |
| Preis | Kostenlos | Kostenlos / kostenpflichtige Stufen | Kostenlos |
Funktionen
Formatieren und minifizieren
Beide Richtungen, mit der Einrücktiefe unter Ihrer Kontrolle und Tabulatoren, wo ein Projekt sie verlangt.
Wohlgeformtheitsprüfung
Unausgeglichene Tags, streunende Und-Zeichen und ungültige Namen werden mit Zeile und Spalte gemeldet.
Warnungen zur Leerraumsicherheit
Elemente mit gemischtem Inhalt oder bedeutsamem Text werden markiert, bevor Einrückung sie umschreiben würde.
Attributreihenfolge unangetastet
Attribute bleiben in Dokumentreihenfolge, weil manche Verbraucher und manche Signaturen davon abhängen.
CDATA und Kommentare erhalten
Abschnitte bleiben wortgetreu, samt des Inhalts, der sonst maskiert werden müsste.
Große Dokumente möglich
Ein Export von mehreren Megabyte wird ohne Upload und ohne Größenobergrenze formatiert.
Nichts zu installieren
Kein Build-Werkzeug, keine Laufzeitumgebung, keine Abhängigkeiten — es läuft in der Webseite.
Bereit für Arabisch und RTL
Die vollständige Oberfläche in acht Sprachen, einschließlich Arabisch von rechts nach links.
Standardmäßig sicher
Über HTTPS ausgeliefert, ohne Inhaltsverfolgung und ohne Upload an Dritte.
Wer es nutzt
Integrationsentwicklung
Eine SOAP-Antwort lesen, die in einer einzigen ununterbrochenen Zeile ankam.
Buchhaltung und Fakturierung
Eine elektronische Rechnung prüfen, die eine Behörde zurückgewiesen hat.
Systemadministration
Eine Konfigurationsdatei aufräumen, bevor sie in die Versionsverwaltung geht.
Wer eine API debuggt
Das eine unmaskierte Und-Zeichen finden, an dem ein Dokument scheiterte.
Häufig Gestellte Fragen
Nein. Alles läuft lokal im Browser — Ihr Text wird nie hochgeladen, gespeichert oder geteilt.
Ja — komplett kostenlos, ohne Konto und ohne Limits.