Was ist der Unterschied zwischen well-formed und valid XML?

Well-formed heißt nur: die Syntax stimmt — ein Root-Element, korrekt geschlossene Tags, escapete Sonderzeichen. Valid heißt zusätzlich: das Dokument hält ein XSD- oder DTD-Schema ein, also Reihenfolge, Pflichtfelder, Datentypen und Werte. Der Editor prüft beides separat — Text-Parse für well-formed, XSD-Tab für valid.

Wie schreibe ich XPath für Elemente in einem Namespace?

Im Browser (XPath 1.0) gibt es zwei Wege: einen Namespace-Resolver übergeben, oder per local-name() umgehen: //*[local-name()='Envelope']/*[local-name()='Body']. Für SOAP/SAML-Debugging ist die local-name()-Variante pragmatisch, weil sie ohne Resolver-Setup funktioniert.

Was ist XXE und warum ist es gefährlich?

XML External Entity Injection lässt einen Angreifer per <!DOCTYPE>-Block Dateien vom Server lesen, interne Netzwerk-Requests auslösen oder den Parser einfrieren. Mitigationen: DTDs und Entities im Parser deaktivieren, niemals libxml_disable_entity_loader(false) setzen, in Java FEATURE_SECURE_PROCESSING aktiv lassen. OWASP listet XXE in den Top 10.

Kann ich XSLT 3.0 oder XPath 3.1 hier nutzen?

Native Browser unterstützen XSLT 1.0 und XPath 1.0. Für XSLT/XPath 3.x braucht es Saxon-JS oder serverseitiges Saxon. Der Editor nutzt den Browser-Default; für komplexere Transformationen mit Higher-Order-Funktionen oder xsl:try empfehlen wir Saxon-HE in einer Build-Pipeline.

Wie konvertiere ich XML verlustfrei nach JSON?

Verlustfrei geht es streng genommen nicht — XML kennt Mixed Content, Attribute, Reihenfolge und Processing Instructions, JSON nicht. Pragmatisch nutzt fast-xml-parser Konventionen: @_-Präfix für Attribute, #text für Text. Beim Rückweg muss der Builder dieselben Konventionen kennen, sonst landen Attribute fälschlich als Kinder.

Werden meine XML-Daten an euren Server geschickt?

Editing, XPath, XSLT und JSON/CSV-Konvertierung laufen lokal im Browser — nichts wird gesendet. Nur die optionalen Funktionen XSD-Validierung und XSD-Generierung nutzen einen Server-Helper (libxml2), weil der Browser das nicht nativ kann. Die Daten werden dort verarbeitet und sofort verworfen, nichts gespeichert.

Startseite
Encoding & Datenformate
XML Editor

XML Editor

Tree-View, XPath, XSLT, XSD — alles in einem Werkzeug, wie Altova XMLSpy.

{{ stats.size }} {{ __t('bytes') }} {{ stats.elements }} {{ __t('elements') }} {{ stats.attributes }} {{ __t('attributes') }} {{ stats.depth }} {{ __t('depth') }} {{ stats.textNodes }} {{ __t('text_nodes') }}

{{ __t('xpath_examples_label') }}: {{ ex }}

{{ __t('schema_errors_heading') }} ({{ schemaResult.errors.length }}):

L{{ err.line }}{{ err.column ? ':' + err.column : '' }} {{ err.message }}

{{ __t('convert_output_label') }} ({{ convertTarget.toUpperCase() }})

Was ist der CalcSI XML Editor?

Der CalcSI XML Editor ist ein kostenloses Online-Werkzeug im Stil von Altova XMLSpy. Du kannst XML-Dokumente komfortabel in einer voll editierbaren Baum-Ansicht oder als reinen Text bearbeiten — inklusive XPath-Tester, XSLT-Transformation, XSD-Validierung und automatischer Schema-Generierung.

Bearbeitung, XPath-Abfragen und XSLT-Transformationen laufen direkt im Browser. Für XSD-Schema-Validierung und automatische Schema-Generierung nutzen wir die libxml-Bibliothek auf unserem Server — schnell, standardkonform und ohne dass du Software installieren musst.

Funktionsumfang

Voll editierbarer Tree-View — Doppelklick auf Tag, Attribut oder Text zum Bearbeiten. Hinzufügen, Löschen und Verschieben per Inline-Buttons.
Text-Ansicht — Klassischer Editor mit monospace-Font und sofortiger Fehlermarkierung (Zeile/Spalte).
XPath-Tester — Beliebige XPath-Ausdrücke gegen das XML laufen lassen, Treffer als XML, Text, Zahl oder Boolean.
XSLT-Transformation — XML + Stylesheet → HTML/XML/Text. Direkt im Browser via XSLTProcessor.
XSD-Schema-Validierung — Echte W3C-konforme Validierung via libxml auf unserem Server. Fehler mit Zeile und Spalte.
XSD aus XML generieren — Wir analysieren ein Beispiel-XML und schlagen ein passendes XSD mit Typen und Kardinalitäten vor.
Konvertierung — XML nach JSON oder CSV (für tabellarische XML-Listen).
Import & Export — Datei hochladen, von URL laden, als .xml herunterladen, in die Zwischenablage kopieren.

Typische Anwendungsfälle

SOAP-Requests/Responses, B2B-Nachrichten und EDI-Daten inspizieren und korrigieren
Konfigurationsdateien (pom.xml, web.xml, applicationContext.xml) bearbeiten und validieren
RSS-/Atom-Feeds prüfen und nach Bedarf in JSON umwandeln
SVG-Dateien als XML bearbeiten — Attribute, Pfade, ViewBoxes anpassen

Daten und Datenschutz

Die Bearbeitung, XPath-Abfragen, XSLT-Transformationen und JSON-/CSV-Konvertierung laufen vollständig in deinem Browser — diese Daten verlassen dein Gerät nicht. Nur für XSD-Schema-Validierung und automatische Schema-Generierung wird das XML (zusammen mit einem optionalen XSD) zu unserem Server geschickt, dort verarbeitet und sofort wieder verworfen — wir speichern nichts.

XML im Detail: W3C-Standard, Schema und XPath

XML wurde 1998 als W3C Recommendation veröffentlicht und ist trotz der JSON-Dominanz weiterhin Standard in vielen Bereichen: SOAP-Webservices, SEPA-/ISO-20022-Finanztransaktionen, RSS/Atom-Feeds, SVG-Grafiken, Office-Dokumente (DOCX, ODF), Android-Layouts, Maven/Gradle-Configs und EDI-Austausch. Im Gegensatz zu JSON unterstützt XML Namespaces (xmlns:soap="…"), Attribute auf Elementen, Mixed Content (Text + Kinderknoten), Kommentare, CDATA-Blöcke und Processing Instructions. Diese Ausdruckskraft macht XML mächtiger, aber auch komplexer.

Drei W3C-Standards begleiten XML praktisch jeden Tag: XSD (XML Schema Definition) beschreibt Struktur, Typen und Constraints (vergleichbar mit JSON Schema, aber älter und strenger); XPath (aktuell 3.1) ist eine deklarative Abfragesprache für XML-Knoten, etwa //book[author='Anna']/title; und XSLT transformiert XML in HTML, andere XML-Strukturen oder Plain Text. Dieser Editor stellt alle drei zur Verfügung: Sie bearbeiten im Tree- oder Text-View, validieren gegen Ihr XSD, testen XPath-Ausdrücke und führen XSLT-Transformationen direkt im Browser oder per Server-Helper aus.

Wer von JSON kommt, stolpert oft über drei Eigenheiten: erstens den Prolog — eine Datei sollte mit einer Deklaration wie <?xml version="1.0" encoding="UTF-8"?> beginnen. Zweitens das Root-Element: XML braucht genau eins, während JSON beliebig viele Top-Level-Werte erlaubt. Drittens die Trennung von Attributen und Kindknoten: in XML <user id="42">Anna</user> existieren ID und Name auf verschiedenen "Ebenen" — beim Konvertieren in JSON taucht das typischerweise als {"id":"42","#text":"Anna"} oder mit Präfix @_id auf.

So nutzen Sie den XML Editor

Fünf konkrete Workflows decken die häufigsten Aufgaben ab:

XML inspizieren und editieren: fügen Sie das Dokument in den Text-Mode ein oder laden Sie eine Datei. Wechseln Sie in den Tree-Mode, um Elemente, Attribute und Kommentare strukturiert zu sehen. Klick auf einen Knoten erlaubt Rename, neuen Child hinzufügen oder Löschen.
XPath-Knoten finden: im XPath-Tab geben Sie z.B. //book[price < 20]/title ein, um alle Buchtitel unter 20 Euro zu listen. Der Tester nutzt den nativen document.evaluate des Browsers (XPath 1.0) und gibt Treffer mit Pfad-Kontext zurück.
XSD validieren: laden Sie Ihr Schema in das XSD-Feld oder generieren Sie eines automatisch aus dem aktuellen XML. Der Server-Helper liefert eine Liste konkreter Fehler mit Zeilennummer (Element 'price' is not allowed here), die im Editor highlightet werden.
XSLT transformieren: fügen Sie ein Stylesheet ein und erzeugen Sie aus dem XML einen HTML-Report, eine andere XML-Struktur oder Plain Text. Klassischer Use-Case: SEPA-XML in eine menschenlesbare Liste verwandeln.
Zu JSON/CSV konvertieren: über den Convert-Tab wandelt der Editor das XML mit fast-xml-parser in eine JSON-Repräsentation. Attribute werden mit Prefix @_ abgebildet, Text-Knoten als #text — Standardkonvention für die spätere Weiterverarbeitung.

Praxisbeispiele

Diese typischen XML-Szenarien kommen täglich vor:

Minimaler XML-Prolog: <?xml version="1.0" encoding="UTF-8"?><root><item id="1">Anna</item></root> — komplettes wohlgeformtes Dokument mit Encoding-Hinweis.
XPath-Filter: aus einem Bookstore-XML liefert //book[@category='fiction']/title/text() alle Buchtitel der Kategorie Fiction. Die text()-Funktion extrahiert reine Textknoten.
Attribut vs. Element: <user id="42">Anna</user> wird in JSON zu {"@_id":"42","#text":"Anna"}. Beim Roundtrip XML→JSON→XML muss der Builder wissen, welche Felder Attribute waren.
CDATA-Block: <script><![CDATA[ if (a < b) doStuff(); ]]></script> bewahrt rohen Text mit <-Zeichen, ohne sie als Tag zu interpretieren — wichtig für SOAP-Payloads mit eingebettetem Code.
Namespace: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">. Der Präfix soap: referenziert die deklarierte URI; XPath-Abfragen müssen mit local-name() arbeiten oder den Namespace registrieren.

Grenzen, Edge Cases und Sicherheit

XML hat ein paar Klassiker, die regelmäßig in Production knallen. Erstens: XXE (XML External Entity). Ein Angreifer schiebt <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]><foo>&xxe;</foo> ein — ein naiv konfigurierter Parser liest die Datei aus und gibt sie zurück. Best Practice: DTDs und externe Entitäten deaktivieren (libxml2 LIBXML_NONET | LIBXML_NOENT deaktivieren, Java setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)). Zweitens: Billion Laughs / XML Bomb. Verschachtelte Entitäten (&lol1; → &lol2; → ...) blasen ein 1-KB-Dokument zu Gigabytes auf — auch hier hilft das Deaktivieren von Entity-Expansion. Drittens: Namespace-Hölle. SOAP- und SAML-Dokumente arbeiten mit mehreren Namespaces gleichzeitig; XPath 1.0 (Browser-Default) verlangt registrierte Namespace-Resolver, sonst bleiben Anfragen leer. Lösung: local-name()-Workaround oder ein XPath-2/3.1-Library. Viertens: Encoding-Falle. XML-Prolog deklariert das Encoding (encoding="UTF-8"); stimmt das nicht mit dem tatsächlichen Charset überein, scheitert der Parse mit "invalid character". Bei Legacy-Daten erst per iconv normalisieren. Fünftens: JSON-Roundtrip ist nicht verlustfrei. XML hat Konzepte (Mixed Content, Reihenfolge von Geschwistern, Processing Instructions), die JSON nicht abbildet. Ein <p>Hallo <b>Welt</b> gut?</p> wird in JSON eine kreative Approximation.

Häufige Fragen zum XML Editor

Was ist der Unterschied zwischen well-formed und valid XML?: Well-formed heißt nur: die Syntax stimmt — ein Root-Element, korrekt geschlossene Tags, escapete Sonderzeichen. Valid heißt zusätzlich: das Dokument hält ein XSD- oder DTD-Schema ein, also Reihenfolge, Pflichtfelder, Datentypen und Werte. Der Editor prüft beides separat — Text-Parse für well-formed, XSD-Tab für valid.
Wie schreibe ich XPath für Elemente in einem Namespace?: Im Browser (XPath 1.0) gibt es zwei Wege: einen Namespace-Resolver übergeben, oder per local-name() umgehen: //*[local-name()='Envelope']/*[local-name()='Body']. Für SOAP/SAML-Debugging ist die local-name()-Variante pragmatisch, weil sie ohne Resolver-Setup funktioniert.
Was ist XXE und warum ist es gefährlich?: XML External Entity Injection lässt einen Angreifer per <!DOCTYPE>-Block Dateien vom Server lesen, interne Netzwerk-Requests auslösen oder den Parser einfrieren. Mitigationen: DTDs und Entities im Parser deaktivieren, niemals libxml_disable_entity_loader(false) setzen, in Java FEATURE_SECURE_PROCESSING aktiv lassen. OWASP listet XXE in den Top 10.
Kann ich XSLT 3.0 oder XPath 3.1 hier nutzen?: Native Browser unterstützen XSLT 1.0 und XPath 1.0. Für XSLT/XPath 3.x braucht es Saxon-JS oder serverseitiges Saxon. Der Editor nutzt den Browser-Default; für komplexere Transformationen mit Higher-Order-Funktionen oder xsl:try empfehlen wir Saxon-HE in einer Build-Pipeline.
Wie konvertiere ich XML verlustfrei nach JSON?: Verlustfrei geht es streng genommen nicht — XML kennt Mixed Content, Attribute, Reihenfolge und Processing Instructions, JSON nicht. Pragmatisch nutzt fast-xml-parser Konventionen: @_-Präfix für Attribute, #text für Text. Beim Rückweg muss der Builder dieselben Konventionen kennen, sonst landen Attribute fälschlich als Kinder.
Werden meine XML-Daten an euren Server geschickt?: Editing, XPath, XSLT und JSON/CSV-Konvertierung laufen lokal im Browser — nichts wird gesendet. Nur die optionalen Funktionen XSD-Validierung und XSD-Generierung nutzen einen Server-Helper (libxml2), weil der Browser das nicht nativ kann. Die Daten werden dort verarbeitet und sofort verworfen, nichts gespeichert.