How to Convert JSON to XML Online
Converting JSON to XML is a routine task for integration developers working with SOAP web services, enterprise middleware, and legacy systems that predate JSON. This converter handles the transformation in four steps — no code, no libraries, no setup required.
Step 1 — Paste your JSON. Copy the JSON object or array from your source — an API response, a database export, a webhook payload — and paste it into the input panel. The converter accepts any valid JSON: flat objects, deeply nested objects, arrays, and combinations of all three.
Step 2 — Set the root element name. XML requires a single root element that wraps all content.
JSON has no equivalent concept, so you specify the root tag manually. Enter a meaningful name — root,
data, order, customer, or whatever matches the domain. For SOAP
integrations this often corresponds to the outer element of the SOAP body payload. The root element name is
the only piece of configuration required.
Step 3 — Convert. Click Convert to run the transformation. The converter
maps every JSON key to an XML element, recurses into nested objects, and repeats elements for array entries.
The output is well-formed XML with proper indentation and UTF-8 encoding. Special characters in values
(&, <, >) are automatically escaped.
Step 4 — Copy or download. Click Copy to put the XML on your clipboard for
immediate use, or click Download to save a .xml file. The downloaded file is
ready to attach to a SOAP request, import into an ETL tool, or commit to your repository.
Why Convert JSON to XML?
JSON has dominated API design since the early 2010s, but large portions of the enterprise software landscape still operate on XML. Knowing when and why to convert JSON to XML is important context for choosing the right approach.
SOAP web services. SOAP (Simple Object Access Protocol) is the web service standard used across finance, healthcare, government, and enterprise software. Every SOAP message is an XML document. Modern REST APIs return JSON; SOAP services expect XML. When your integration must call a SOAP endpoint with data that originated as JSON — from a CRM, an e-commerce platform, or a webhook — converting JSON to XML is the necessary first step before wrapping the payload in a SOAP envelope.
Legacy enterprise systems. ERP systems including SAP and Oracle E-Business Suite have XML as their native integration format. SAP's iDocs, BAPIs, and many XI/PI/PO message formats are XML. When feeding data into these systems from modern JSON-based sources, you need clean, well-formed XML that matches the system's expected element structure.
EDI feeds and B2B data exchange. Electronic Data Interchange (EDI) has largely moved toward XML variants — RosettaNet, cXML, and UBL (Universal Business Language) are all XML-based. Companies exchanging purchase orders, invoices, and shipping notices with trading partners often need to produce XML-structured documents from JSON data in their internal systems.
Configuration and markup formats. Tools like Ansible, Maven, Spring, and many CI/CD platforms still use XML configuration. If you have structured data in JSON — build parameters, deployment configs, feature flags — converting to XML lets you adapt that data for XML-based tooling without rewriting it by hand.
How JSON Objects Map to XML Elements
The core rule of JSON-to-XML conversion is: keys become element names, values become element content. Understanding the full mapping lets you predict and control the output structure.
Flat objects. A flat JSON object becomes a sequence of sibling elements inside the root:
// JSON input
{
"name": "Acme Corp",
"country": "US",
"active": true
}
<!-- XML output (root element: "company") -->
<company>
<name>Acme Corp</name>
<country>US</country>
<active>true</active>
</company>Nested objects. Nested JSON objects become nested XML elements. The nesting depth is preserved exactly:
// JSON input
{
"order": {
"id": 9021,
"billing": {
"city": "Austin",
"state": "TX"
}
}
}
<!-- XML output (root element: "root") -->
<root>
<order>
<id>9021</id>
<billing>
<city>Austin</city>
<state>TX</state>
</billing>
</order>
</root>Arrays. JSON arrays produce repeated XML elements with the same tag name — one element per array entry. The element name is derived from the key that holds the array:
// JSON input
{
"tags": ["api", "crm", "billing"]
}
<!-- XML output -->
<root>
<tags>api</tags>
<tags>crm</tags>
<tags>billing</tags>
</root> Null values. JSON null maps to an empty self-closing element:
<fieldName />. This preserves the presence of the field in the XML output without
outputting a literal string "null", which would be incorrect for many XML consumers.
Special characters. Any value that contains &, <,
>, ", or ' is automatically XML-escaped to the corresponding
entity reference, ensuring the output is always well-formed regardless of the source data.
JSON to XML for SOAP API Integration
SOAP integrations are the most common reason enterprise developers need to convert JSON to XML. Understanding the SOAP envelope structure helps you use the converter output correctly.
A SOAP message is an XML document with a specific structure. The outermost element is the
Envelope, which contains an optional Header (for authentication tokens like
WS-Security UsernameToken) and a required Body. The Body contains the operation payload — the
actual data elements your target service expects.
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ord="http://example.com/orders">
<soapenv:Header>
<!-- WS-Security or other header tokens go here -->
</soapenv:Header>
<soapenv:Body>
<ord:CreateOrder>
<!-- paste converted JSON-to-XML output here -->
<orderId>10482</orderId>
<status>pending</status>
<customer>
<name>Priya Patel</name>
<email>[email protected]</email>
</customer>
</ord:CreateOrder>
</soapenv:Body>
</soapenv:Envelope>
The workflow is: convert your JSON payload here, set the root element name to match the SOAP operation name
(e.g. CreateOrder), copy the XML output, then paste it inside the soapenv:Body of
your SOAP template. Add the appropriate namespace declarations to match your WSDL.
For teams with recurring SOAP integrations, Koodisi's integration platform automates this transformation inside integration workflows — mapping JSON from REST source APIs to XML for SOAP target endpoints without manual conversion steps.
Handling Arrays and Nested Objects in XML Conversion
Arrays are the most structurally significant difference between JSON and XML, and they deserve detailed treatment. JSON arrays are ordered sequences of values under a single key. XML has no native array type — sequences are represented by repeating sibling elements with the same tag name.
Arrays of primitives produce repeated elements named after the key, each containing one primitive value (as shown in the mapping section above). Arrays of objects produce repeated elements, each containing the sub-elements of one object:
// JSON input
{
"items": [
{ "sku": "WIDGET-01", "qty": 2 },
{ "sku": "GADGET-03", "qty": 1 }
]
}
<!-- XML output -->
<root>
<items>
<sku>WIDGET-01</sku>
<qty>2</qty>
</items>
<items>
<sku>GADGET-03</sku>
<qty>1</qty>
</items>
</root>
Some XML consumers prefer a wrapper element around repeated items — for example, <itemList>
wrapping each <item>. If your target system requires this pattern, the standard approach is
to restructure the JSON before conversion: add the wrapper key and rename the array items. In the example
above, you would change the JSON to { "itemList": { "item": [...] } } before converting.
Deeply nested objects are handled without depth limits. A five-level-deep JSON object becomes a five-level-deep XML tree. The converter preserves the exact hierarchy, which is correct for most integration scenarios. For systems with strict schema requirements (defined by an XSD), validate the output against the XSD to confirm element names and nesting align with what the target system expects.
Mixed arrays — arrays containing both objects and primitives — are uncommon in well-structured APIs but do appear in legacy data. The converter handles them by rendering primitives as text content and objects as nested elements within the same repeated tag, though the result may require manual adjustment to pass XSD validation.
JSON to XML vs XML to JSON: Choosing the Right Direction
Integration work often requires converting in both directions depending on which system is the source and which is the target. Understanding when to use each direction helps you design cleaner integration architectures.
JSON to XML is the right direction when your data originates in a modern REST API or JSON-native database and your target is an XML-based system: a SOAP service, a legacy ERP, an EDI feed, or an XML configuration file. This is the most common direction for organizations modernizing outbound integrations — new systems produce JSON, old systems consume XML.
XML to JSON is the right direction when your data source is a legacy system that produces XML and your target is a modern REST API, a JSON-native database, or a frontend application. This is the most common direction for inbound integrations — reading an XML response from a SOAP service and passing the data to a REST-based workflow engine or a cloud application.
In bidirectional integrations — where two systems need to exchange data and each speaks a different format — the best pattern is a canonical JSON model in the middle. Data from the XML system is converted to JSON (normalized to the canonical model), processed, and then converted back to XML before being sent to the XML consumer. This canonical approach prevents the proliferation of direct format-to-format conversions as the number of systems in the integration mesh grows.
A key architectural consideration: round-trip fidelity. Converting JSON to XML and back to JSON does not always produce the original JSON. Array handling, attribute vs element choices, and namespace prefixes all introduce differences. If you need round-trip fidelity, define an explicit mapping rather than relying on automatic conversion in both directions.
JSON to XML in Enterprise Integration Workflows
Enterprise integration workflows regularly require JSON-to-XML transformation as a pipeline step — not just a one-off manual conversion. Understanding where this conversion fits in a larger workflow helps integration architects make better design decisions.
ERP integrations (SAP, Oracle). SAP S/4HANA and SAP ECC expose many functions via BAPI (Business Application Programming Interface) calls that use XML-based IDoc or RFC formats. Oracle E-Business Suite integration points often expect XML payloads conforming to defined XSDs. When your source of truth is a SaaS platform with a REST API — a CRM, an e-commerce platform, a warehouse management system — data must be converted from JSON to XML before being passed to the ERP. This converter handles ad-hoc or one-off transformations; for automated recurring workflows, Koodisi's integration platform manages the transformation as a reusable, monitored step in a visual workflow.
SFTP file-based feeds. Many enterprise systems consume data via scheduled file drops on SFTP servers. The files are often XML: XML purchase orders, XML invoices, XML inventory updates. If your internal system stores data as JSON or exposes a JSON API, generating the XML file for the SFTP drop requires a JSON-to-XML conversion step. Testing the conversion manually here before automating it in a pipeline is a reliable way to validate the output format before production.
EDI and B2B integration. Electronic Data Interchange with trading partners — retailers, logistics providers, manufacturers — often uses XML-based formats like cXML (Ariba) or UBL. JSON-originated data from procurement or supply chain systems must be converted and restructured to match the EDI partner's expected XML schema. The converter produces the raw XML structure; a final mapping step aligns element names with the EDI standard's vocabulary.
Configuration automation. Infrastructure-as-code and DevOps workflows sometimes require generating XML configuration files (Maven POM files, Spring bean definitions, Ant build scripts, JMeter test plans) from structured data held in JSON. Converting a JSON configuration template to XML programmatically reduces manual editing and the XML syntax errors that come with it.
For teams running more than a handful of JSON-to-XML conversions per week, automating the transformation inside an integration platform is more sustainable than repeated manual conversion. Koodisi's integration platform provides a JSON-to-XML transform activity that runs inline in workflows, with configurable root element names, namespace prefixes, and attribute mapping — removing the need for custom transformation code in every integration project.
Frequently Asked Questions
Does the converter handle JSON arrays correctly?
Yes. JSON arrays are converted to repeated sibling XML elements sharing the same tag name, which is the standard XML representation of sequences. Each element in a primitive array becomes a text-content element; each element in an object array becomes a nested element group. The converter handles arrays at any depth, including arrays of arrays and arrays of mixed-type values.
What happens to JSON null values in the XML output?
JSON null values are rendered as empty self-closing XML elements — for example,
<middleName />. This preserves the presence of the field in the XML document without
outputting the string "null", which would be misleading to XML consumers that interpret element text content
literally. If your target system uses xsi:nil="true" for null values, you will need to manually
add that attribute to the relevant elements after conversion.
Can I output XML attributes instead of nested elements for certain fields?
The automatic converter renders all JSON keys as child elements, which is the safest default for compatibility
with XSD-validated systems. If your target schema requires specific fields to appear as XML attributes (e.g.
<item id="001"> instead of <item><id>001</id></item>),
the recommended approach is to post-process the XML output manually or use an XSLT transformation to move
those fields to attributes. Some JSON-to-XML libraries support an attribute convention (prefixing keys with
@), which requires structuring the source JSON accordingly before converting.
Is there a file size limit for JSON input?
The converter runs entirely in your browser — no data is sent to a server. Performance is limited by your browser's JavaScript engine rather than a server-side file size cap. In practice, JSON objects up to a few megabytes convert in under a second on modern hardware. Very large files (tens of megabytes) may cause the browser tab to slow briefly during conversion but will complete without errors.
Can I convert XML back to JSON with this tool?
This page converts JSON to XML. To go in the other direction, use the XML to JSON converter — it handles the reverse transformation: parse an XML document and produce a clean JSON object, with options for how to handle XML attributes and namespaces.