JSON to XML

What a JSON to XML converter has to decide

Modern services trade JSON, but huge swathes of enterprise infrastructure still speak XML — SOAP APIs, B2B EDI feeds, banking middleware, telecom OSS/BSS systems, and government data exchanges. When the system on the other end of the integration only accepts XML, you need a fast way to translate. The mapping runs in your browser, deterministically: every JSON key becomes an XML element, nested objects become nested elements, and arrays repeat the same tag for each item.

Two decisions are worth knowing before you paste anything, because they are where converters differ from each other. First, everything is wrapped in a single <root> element — XML allows exactly one root and JSON does not have the concept, so something has to be invented. Rename it after conversion if your schema expects a different name. Second, a top-level array becomes one <root> holding one <item> per entry, for the same reason: three sibling elements at the top of a file is not a document, it is three fragments, and the well-formedness rules in XML 1.0 are explicit about it. Output carries a UTF-8 declaration and escapes &, <, >, " and ' in content. For the source format, the official JSON specification and RFC 8259 are the canonical references.

How to use the JSON to XML converter

1. Paste Your JSON – Drop your JSON object or array into the left panel. Either works — an object becomes the contents of <root>, and an array becomes <root> with one <item> per entry.
2. Watch the Conversion – XML is generated automatically as you type. The right panel updates in real time with no Convert button needed.
3. Check Element Names – Every JSON key becomes an XML element name. Characters XML does not allow in a name are replaced with underscores, and a leading digit gets an underscore in front of it, so the output stays well-formed.
4. Inspect Arrays – Array items repeat the parent's tag name — a "sectors" array of two objects becomes two <sectors> elements, not <sectors_item>. This matches the most common JSON-to-XML mapping convention.
5. Copy or Download – Use Copy to put the XML on your clipboard, or Download to save it as a .xml file ready for your integration.

Pro Tip: If the target system needs XML attributes rather than elements, prefix the JSON key with @. {"@id": "BS-4471", "vendor": "Ericsson"} comes out as <root id="BS-4471"><vendor>Ericsson</vendor></root>. Only scalars can be attributes — XML attributes hold text — so an @ key whose value is an object or an array is emitted as an ordinary child element instead.

Example

A base-station configuration. Note the <code>&lt;root&gt;</code> the converter adds, and the two <code>&lt;sectors&gt;</code> elements — array items reuse the parent's tag name rather than inventing one.

{
  "baseStation": {
    "id": "BS-4471",
    "vendor": "Ericsson",
    "sectors": [
      { "tac": 12001, "band": "n78" },
      { "tac": 12002, "band": "n28" }
    ]
  }
}

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <baseStation>
    <id>BS-4471</id>
    <vendor>Ericsson</vendor>
    <sectors>
      <tac>12001</tac>
      <band>n78</band>
    </sectors>
    <sectors>
      <tac>12002</tac>
      <band>n28</band>
    </sectors>
  </baseStation>
</root>

Common Use Cases

Integrating With Legacy SOAP APIs

Plenty of carrier billing, finance, and government APIs still accept only SOAP — and SOAP envelopes are XML to their bones. If your application produces JSON internally but needs to call one of these services, this converter is the bridge. Drop the JSON in, take the XML out, wrap it in your SOAP envelope, and you're done.

Generating XML for Configuration Files

Many telecom network elements (HSS, MME, SGSN) and database systems still load configuration from XML. If your config lives in a JSON-first source (a git-tracked config-as-code repo, for instance), convert it here as part of your build step. MDN's XML reference is a good companion when you're double-checking the output structure.

Producing RSS / Atom / Sitemap Feeds

RSS, Atom, and sitemap.xml are all XML with strict element vocabularies. If your content management system stores entries as JSON, convert each entry here and drop the results inside the feed's own wrapper — you will want to strip the generated <root> and rename the item elements to <item> or <entry>, since a feed reader matches on those exact names. The RSS 2.0 specification is the shortest of the three and worth keeping open while you map fields.

Key Features

• Real-Time Conversion – Output updates as you type; no Convert button to click.
• Always One Root – Output is wrapped in <root>, and a top-level array becomes <root> with one <item> per entry, so what you copy is a document rather than a pile of fragments.
• Well-Formed XML Output – Includes the standard <?xml version="1.0" encoding="UTF-8"?> declaration and escapes &, <, >, " and ' in both text and attribute values.
• Nested Structures – Arbitrarily deep JSON objects and arrays are walked recursively to produce matching XML hierarchies.
• Attribute Support – A key prefixed with @ and holding a scalar becomes an attribute on the enclosing element instead of a child.
• Long Integers Survive – An ICCID such as 8901240544102066246 comes out with all 19 digits; it is never routed through a JavaScript number on the way.
• Privacy First – Conversion runs entirely in your browser; nothing is uploaded.

Frequently Asked Questions

How are JSON arrays represented in XML?

Each array item is emitted as a separate element carrying the parent key's name. "sectors": [{...}, {...}] becomes <sectors>...</sectors> twice — siblings, not a container with children. This is the most common convention but not the only one; some systems want a wrapper (<sectors><item>...</item></sectors>), which you get by wrapping the array in an object first. An array at the very top of the document is the one place the wrapper is unavoidable, and there you get <root> with <item> children.

What is the <root> element and can I change it?

It is added by the converter, and you will need to rename it. JSON has no equivalent of a document element — {"baseStation": {...}} is a value, not a document — while XML requires exactly one. Rather than promote the first key and behave differently depending on how many keys you happened to have, the output is always wrapped in <root>. A find-and-replace on the opening and closing tag is all it takes to match a schema that expects something else.

What happens with JSON keys that aren't valid XML element names?

Characters outside A-Z a-z 0-9 _ - are replaced with underscores, and a name starting with a digit gets an underscore in front of it — so "cell id" becomes <cell_id> and "5g" becomes <_5g>. Names beginning with the letters "xml" are left exactly as written: the Name production in XML 1.0 reserves that prefix for future standardisation but does not make it ill-formed, and silently renaming a key you deliberately called xmlLang would be the more surprising behaviour.

How are null values converted?

XML has no null. A JSON null becomes an empty element pair — "rsrp": null gives you <rsrp></rsrp>, which is exactly equivalent to <rsrp/> to any parser but is what the output literally contains. Note this is indistinguishable from an empty string, so if the difference matters downstream you want the xsi:nil="true" convention from XML Schema, added as a post-processing step.

Does the tool handle namespaces?

Not automatically — namespaces need explicit prefix declarations (xmlns:foo="...") and JSON has no notion of them. Add the xmlns declarations to <root> yourself after conversion. Be aware that a prefixed name has to be written out by hand rather than coming from a JSON key: a colon is not one of the characters the element-name sanitiser keeps, so "soap:Body" arrives as <soap_Body> and needs correcting. If you are producing SOAP envelopes regularly, generating the envelope from a template and pasting only the body in is less error-prone than converting the whole message.

Is my data safe?

Yes. The conversion is implemented entirely in client-side JavaScript. Neither the input JSON nor the output XML is sent over the network, cached, or logged.

Related Tools

Useful Resources

• W3C XML 1.0 Specification – Authoritative grammar for what counts as well-formed XML.
• RFC 8259 – The IETF JSON specification, source format for the conversion.
• JSON.org – Original JSON spec with railroad-style grammar diagrams.
• MDN XML Reference – Approachable XML documentation for developers more familiar with web standards.
• Stack Overflow JSON+XML – Community answers for JSON-to-XML mapping edge cases.