Data

XML Converter

Convert XML into JSON, YAML, TOML, JavaScript object literals, or PHP arrays. The browser XML parser reads your document, then a structured mapping turns elements into keys, repeated siblings into arrays, and attributes into prefixed fields so the output keeps the original shape. It handles everyday XML sources — SOAP responses, RSS and Atom feeds, sitemaps, SVG, Android and Maven configuration, and legacy API messages — and lets you choose how attributes, text values, numbers, namespace prefixes, and one-item lists are treated. A checks panel summarises the root element, element and attribute counts, namespace prefixes, mixed content, CDATA, and the comments and processing instructions no target format can keep. Parse errors come with line, column, and the offending source line. Parsing, conversion, and copying all happen in this browser tab; nothing is uploaded, proxied, or logged on a server.

  • One XML input feeds five targets — JSON, YAML, TOML, JavaScript object literals, and PHP arrays — each with its own options
  • Attributes map to prefixed keys (configurable, default @) or drop out entirely, and namespace prefixes strip in one click — soap:Body becomes Body
  • Repeated child elements collapse into arrays, or every child element gets an array, so a one-item list is not a different shape downstream
  • Text coerces to real numbers and booleans, and a checks panel reports counts, depth, mixed content, CDATA, key collisions, and dropped constructs
  • Fully local processing — no upload, no telemetry — safe for production messages, SOAP captures, and config samples
0 chars
Waiting for input
Conversion result appears here
Actions

Overview

A focused tool for work that starts from XML. Element-to-key mapping, array collapsing for repeated siblings, attribute handling, and value coercion are resolved at parse time so the output is ready for downstream APIs, configuration loaders, JSON Schema validators, or code generators without a second manual cleanup pass.

  1. 01

    Five target formats out of the box

    XML to JSON, YAML, TOML, JavaScript object literal, and PHP array. JSON and YAML expose indent size, and alphabetical key sort applies to every target; TOML nests tables under the root element and quotes attribute keys such as @name so the result parses; JS object literals keep quoted keys and proper escaping; PHP arrays emit a full <?php return [...]; file.

  2. 02

    Predictable element-to-object mapping

    Each element becomes a key named after its tag, text content becomes the value, and repeated sibling elements collapse into an array in document order. Turn on always-arrays when downstream code should never have to handle both shapes, and the root element name stays the top-level key so the output mirrors the source tree.

  3. 03

    Attributes you control

    Attributes map to keys with a configurable prefix (default @) so they never collide with child element names — and if you clear the prefix and a collision does happen, the checks panel names the key rather than letting the two values merge quietly. Turn attributes off entirely when you only care about element content, and when an element carries both attributes and text the text moves to a #text field.

  4. 04

    Optional value typing

    Numeric and boolean text can be coerced to real numbers and booleans, or kept as strings. Coercion only applies when a value round-trips exactly, so leading-zero codes, version-like strings, phone numbers, and integers beyond the safe range stay as text.

  5. 05

    A checks panel for unfamiliar XML

    The panel summarises the root element, element and attribute counts, nesting depth, namespace prefixes, mixed content, CDATA usage, and how many comments and processing instructions were dropped, so a strange document becomes legible before you trust the conversion.

  6. 06

    Runs entirely in the browser

    Parsing, conversion, checks, and copy all happen on this page using the browser XML parser. Your XML never leaves through a request to a server, CDN, or third-party analytics platform — safe for production messages and config samples.

How to use

The workflow collapses into four steps: paste XML, pick a format, scan the checks panel, and copy the result.

  1. 01

    Paste XML into the input panel on the left. Parsing happens immediately and the checks panel surfaces the root element, counts, namespace prefixes, and mixed-content warnings.

  2. 02

    Pick a target at the bottom: JSON, YAML, TOML, JavaScript object, or PHP array. JSON and YAML add an indent size, key sort applies to every target, and the output updates live as you switch.

  3. 03

    Tune the parse options: keep or drop attributes, change the attribute prefix, strip namespace prefixes, force every child element into an array, and decide whether numeric and boolean text is coerced or kept verbatim.

  4. 04

    Read the checks panel. Mixed content, CDATA, dropped comments, and key collisions are flagged but never block conversion; they mark the places where the document holds something the target format cannot, so you can confirm the shape is what you expect.

  5. 05

    Click copy and paste the output into your IDE, snippet manager, API client, or config loader to continue the workflow.

Details

The recurring rough edges of everyday XML work are smoothed out by default — no need to chain external tools just to get a clean conversion.

  • Parsing uses the same XML engine your browser ships, so well-formedness rules match what other standards-based parsers expect.
  • Repeated sibling elements become arrays in document order, and always-arrays makes even a one-item list an array, so list-like XML maps to predictable JSON, YAML, and TOML.
  • Attribute prefixing keeps attributes and child elements distinct, a single toggle drops attributes when you only need element content, and another strips namespace prefixes from every key.
  • Every target preserves element order, with an opt-in alphabetical sort for stable git diffs, code review, and JSON Schema validation.
  • TOML conversion quotes the keys TOML cannot write bare — @name, xml:lang, #text — so the output parses instead of failing at the first attribute.
  • JavaScript object and PHP array outputs preserve nesting, escaping, and literals so the result drops directly into test data, config, or examples.
  • The checks panel lists the root element, counts, depth, namespace prefixes, and dropped constructs so an unfamiliar XML file becomes legible in seconds.
  • Everything runs in the browser — no SaaS backend — so the tool keeps working on a flight, in a VPN-only network, or behind an enterprise proxy.

Use cases

Whenever the source is XML, the following everyday tasks shed a layer of manual copy-paste or screenshot-and-describe.

  1. Turn SOAP responses into JSON

    Paste a SOAP or legacy XML API response and read it as JSON so you can map fields into a modern client, test data, or a TypeScript type without parsing angle brackets by hand.

  2. Read RSS and Atom feeds as data

    Convert a feed to JSON or YAML to inspect item titles, links, and dates, then feed the structured result into a script, a static-site generator, or a content pipeline.

  3. Migrate XML config to YAML or TOML

    Moving away from web.xml, a Spring XML context, or a Maven pom.xml? See the YAML or TOML output first, then refine by hand instead of retyping the whole tree.

  4. Inspect SVG structure

    Convert an SVG to JSON to walk its groups, paths, and attributes programmatically, or to extract specific attribute values without a full XML DOM library.

  5. Build test data from sample messages

    Backends and partners often share XML samples. Convert them to JSON or JS objects so frontend Jest, Vitest, and Storybook tests can use the same data shape.

  6. Generate PHP config from XML

    Turn a legacy XML settings file into a <?php return [...]; array that drops straight into a Laravel or WordPress project, keeping nesting and escaping intact.

  7. Compare two XML documents

    Convert both files to JSON, then run a structured diff to see exactly which elements, attributes, and values changed between two revisions of a message or config.

  8. Teach and document XML structure

    Convert nested XML to JSON or YAML so example documents read clearly in articles, course notes, and onboarding material without deep angle-bracket indentation.

See also

When the source on your desk is YAML instead — a Kubernetes manifest, a Helm values file, a CI workflow — and you need to walk toward JSON, TOML, XML, JavaScript object literals, or PHP arrays, reach for YAML Converter. If the XML itself needs a cleanup first — pretty-printing a minified message, folding deep nodes, or confirming it is well-formed before you trust the conversion — pass it through XML Formatter, which indents, minifies, and validates XML with line and column error reporting. And when you already have JSON and want to move it into YAML, XML, CSV, TOML, JavaScript objects, or PHP arrays, use JSON Converter to convert in that direction with format-specific options, keeping a single source of truth instead of hand-editing each target.

Best practices

XML carries information in three places at once — elements, attributes, and text — so a clean conversion depends on deciding how each one should map. A few small habits keep results predictable across every project.

  • Decide up front whether attributes matter. Keep them with a clear prefix when they carry data, or drop them when you only need element content.
  • Turn off value coercion when your XML holds identifiers, version strings, leading-zero codes, or phone numbers that must stay as text.
  • Watch for mixed content — text sitting next to child elements. It merges into a #text field, which is rarely what you want; restructure the source if the text is meaningful.
  • Remember that a single occurrence is never wrapped in an array while two or more are, so the same field can arrive as one value and as a list. If a list can hold a single item, turn on always-arrays instead of handling both shapes downstream.
  • After converting XML to JSON, run the result through a JSON diff against the previous version to catch silent field changes before they reach production.
  • XML comments and processing instructions are dropped during conversion, and the checks panel counts them. Promote anything essential into real elements or external documentation.
  • Namespaces stay as literal prefixes on keys (for example soap:Body) until you turn on stripping. Decide which one downstream code expects before you copy the output, since the two shapes are not interchangeable.
  • For very large documents, validate your options against a representative slice first, then convert the full file once the shape looks right.

Limitations

Knowing what the tool does not do keeps you from reaching for it as a full XML IDE, schema validator, or transformation engine.

  • No schema validation: DTD, XML Schema (XSD), and RELAX NG rules are out of scope — a well-formed document is not the same as a valid one.
  • No XSLT or XPath: the tool maps structure to other formats but does not transform with stylesheets or evaluate path expressions.
  • XML comments, processing instructions, and the declaration are not preserved in the output; only elements, attributes, and text are mapped, and the panel reports how many constructs were dropped.
  • Mixed content (text interleaved with child elements) cannot always map cleanly; the text is collected into a #text field and ordering between text and elements is not preserved.
  • Nothing is fetched: external entities, DTD includes, and namespace URLs are never resolved. Entities declared inside the document are expanded by the browser parser, which caps the amplification and reports an error instead of letting a billion-laughs document run away.
  • Round-tripping is not guaranteed: converting XML to JSON and back will not always reproduce the original document byte for byte, since several XML constructs have no direct JSON equivalent.
  • Very large files (multiple megabytes) may slow the browser, but processing stays local — nothing is truncated or uploaded.

FAQ

Common questions cover attribute handling, arrays, value typing, namespaces, and whether data leaves the browser.

How are attributes represented?

By default each attribute becomes a key prefixed with @ (configurable) so it never clashes with a child element name. You can change the prefix or turn attributes off entirely when you only need element content. When an element has both attributes and text, the text is stored under a #text key.

Why did repeated elements become an array?

When an element appears more than once under the same parent, the values collapse into an array in document order — that is the only lossless way to represent siblings in JSON, YAML, or TOML. A single occurrence is not wrapped, so a list that can hold one item would otherwise arrive as either shape. Turn on always-arrays and every child element gets an array, whatever the document happens to contain.

Why is my number still a string?

Value coercion only converts text that round-trips exactly, so "007", "1.0", phone numbers, and integers beyond the JavaScript safe range stay as strings to avoid losing data. Turn off "Parse numbers & booleans" to keep every value as text, which is safest for identifiers and codes.

What happens to namespaces?

By default they are kept literally on the keys, so soap:Body becomes the key "soap:Body". Turn on strip namespace prefixes and the same element becomes "Body", with the xmlns declarations removed as well since nothing binds them any more. Namespace URLs are never resolved either way, and the checks panel lists the prefixes it found.

What does the TOML output look like?

The root element becomes the top-level table, nested elements become nested tables, and repeated siblings become arrays. Keys that TOML cannot write bare — attribute keys such as @name, a namespaced xml:lang, the #text field — are quoted automatically, so the result parses as it stands. TOML has no null and no date type, but neither can come out of an XML document here: an empty element converts to an empty string.

Are comments and CDATA kept?

Comments, processing instructions, and the XML declaration are dropped — only elements, attributes, and text are mapped. CDATA sections are read as ordinary text, and the checks panel notes when CDATA is present so nothing surprises you.

Can I convert the result back to XML?

This tool converts from XML. To go the other way, the JSON Converter and YAML Converter can emit XML. Round-tripping is not guaranteed to be byte-identical because several XML constructs have no direct JSON equivalent.

Does pasted data get uploaded?

No. Parsing, conversion, checks, and copy all happen in the browser using its built-in XML parser. No request carries your XML out of this page to a server, CDN, or analytics platform, so it is safe for production messages and secret sample data.

Related tools

Keep moving through data work: convert in the other direction, pretty-print or validate XML, or reshape JSON for the next step. The tools below chain into a full workflow.