How to convert json to xml for soap api requests
- Step 1Prepare the JSON request body — Paste the JSON object that represents the contents of your SOAP Body — not the envelope itself. Nested objects become nested elements; arrays become repeated siblings. Put attribute values under
@-prefixed keys and any mixed text under#text. - Step 2Name the root element to match the operation — Set Root element to your operation name, e.g.
CreateOrderRequest. For a top-level JSON object this becomes the single wrapping element. For a top-level JSON array, the root wraps the array and each item uses the Array item element name you supply. - Step 3Decide on attributes vs child elements — The default attribute prefix is
@. Any JSON key starting with@is rendered as an attribute. If your schema uses a different convention you can change the prefix (for example to:or$), but every attribute key in the JSON must then use that same prefix. - Step 4Choose indent and the declaration toggle — Pick Minified for a compact body, or 2 / 4 spaces for readability. Leave XML declaration on to emit
<?xml version="1.0" encoding="UTF-8"?>— most clients tolerate it inside a Body, but if your stack rejects a nested declaration, turn it off. - Step 5Convert and copy the fragment — Click Convert to XML, then Copy. You now have a well-formed element tree. Strip the
<?xml ...?>line if you left it on and don't want it inside the Body. - Step 6Wrap it in your envelope and POST — Paste the fragment between
<soap:Body>...</soap:Body>inside asoap:Envelopethat carries the correctxmlnsdeclarations (the tool does not add these). Send withContent-Type: text/xml(SOAP 1.1) orapplication/soap+xml(SOAP 1.2).
How JSON shapes map to SOAP-shaped XML
The exact serialization the converter produces, using the default options (root root, item item, attribute prefix @, text key #text). Behaviour confirmed against the implementation.
| JSON input | XML output | Notes |
|---|---|---|
{ "id": 42 } | <id>42</id> (inside the root) | Scalar object value → child element, numbers emitted unquoted |
{ "items": ["a", "b"] } | <items>a</items><items>b</items> | An array inside an object repeats under its own key — items, not item |
Top-level [ {...}, {...} ] | <root><item>...</item><item>...</item></root> | Only a top-level array uses the Array-item element name |
{ "@id": "b1", "#text": "x" } | <root id="b1">x</root> | @-prefixed key → attribute; #text → element text |
{ "note": "a < b & c" } | <note>a < b & c</note> | All of < > & " ' are entity-escaped |
{ "empty": null } / { "empty": "" } | <empty/> | null and empty string both produce a self-closing empty tag |
The six real options
Every control exposed by the JSON to XML client. There is no namespace, CDATA, envelope, or array-wrapper option — claims to the contrary in older write-ups are inaccurate.
| Option | What it does | Default |
|---|---|---|
| Root element | Name of the single wrapping element around the whole payload | root |
| Array item element | Element name for items of a top-level array only | item |
| Attribute prefix | JSON keys starting with this string are emitted as XML attributes | @ |
| Indent | Minified (single line), 2 spaces, or 4 spaces | 2 spaces |
| Text node name | JSON key whose value becomes the element's text alongside attributes | #text |
| XML declaration | Prepend <?xml version="1.0" encoding="UTF-8"?> | On |
Cookbook
Real JSON → XML conversions for SOAP request bodies, showing the exact output of the converter. Assemble the envelope and namespaces yourself — the tool produces the Body fragment only.
Simple request object → Body fragment
ExampleA flat JSON object with the root named after the operation. Each scalar becomes a child element. You then paste this between your <soap:Body> tags.
Input JSON:
{ "customerId": "C-1001", "amount": 250, "currency": "USD" }
Options: Root element = CreateOrderRequest, indent = 2
Output XML:
<?xml version="1.0" encoding="UTF-8"?>
<CreateOrderRequest>
<customerId>C-1001</customerId>
<amount>250</amount>
<currency>USD</currency>
</CreateOrderRequest>Attributes via the @ prefix
ExampleSOAP schemas frequently mix attributes with text. Put attribute values under @-prefixed keys and the text under #text.
Input JSON:
{ "line": { "@sku": "AB-9", "@qty": "3", "#text": "Widget" } }
Options: Root element = OrderLine
Output XML:
<?xml version="1.0" encoding="UTF-8"?>
<OrderLine>
<line sku="AB-9" qty="3">Widget</line>
</OrderLine>Repeated list elements from a nested array
ExampleAn array inside an object repeats under its own key — which is exactly what most SOAP list structures want. Name the JSON key to match the schema's repeating element.
Input JSON:
{ "lineItems": [ { "sku": "A1" }, { "sku": "B2" } ] }
Output XML:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<lineItems>
<sku>A1</sku>
</lineItems>
<lineItems>
<sku>B2</sku>
</lineItems>
</root>Markup-bearing values are escaped, not CDATA-wrapped
ExampleThere is no CDATA option. A value containing angle brackets is entity-escaped, which is still valid XML and parses identically on the receiving side.
Input JSON:
{ "comment": "Use <b>bold</b> & save 10%" }
Output XML:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<comment>Use <b>bold</b> & save 10%</comment>
</root>Dropping the declaration for an inline Body
ExampleIf your client rejects a nested <?xml?> declaration inside the SOAP Body, turn the declaration off and minify so the fragment is a single inline line.
Input JSON:
{ "ping": "ok" }
Options: XML declaration = off, indent = Minified, Root = HealthCheck
Output XML:
<HealthCheck><ping>ok</ping></HealthCheck>Errors and edge cases
Real errors and silent failures sourced from each platform's own documentation. Match the wording to the row, fix what the row says to fix.
JSON key contains a space or starts with a digit
Not well-formedThe converter writes element names verbatim from JSON keys — it does not sanitize them. A key like "order id" produces <order id>... and "2ndLine" produces <2ndLine>, both of which violate the XML name rules and will fail any SOAP parser. Rename the keys in your JSON first (use json-key-renamer) so every key is a legal XML NCName.
You expected namespace prefixes to be generated
By designThere is no namespace option. If you name the root ord:CreateOrderRequest, the tool emits that literal string as the element name but adds no xmlns:ord declaration, so the document is not namespace-resolvable on its own. Add the xmlns:ord="..." attribute in the envelope you wrap around the fragment, or include it as an @xmlns:ord key in the JSON object.
Invalid JSON pasted
Parse errorThe input is parsed with JSON.parse. A trailing comma, single quotes, or an unquoted key throws a JSON syntax error (e.g. Expected property name or '}') and nothing is converted. Fix the source, or run it through json-format-fixer first to repair common mistakes.
Empty array in the payload
OmittedAn empty array value ("items": []) is dropped entirely — no <items> element appears in the output at all. If your schema requires an empty wrapper element to be present, add a placeholder or post-process the XML.
null and empty-string values collapse to the same tag
ExpectedBoth null and "" serialize to a self-closing empty element (<field/>). The receiving service cannot distinguish 'explicit null' from 'empty string' from the XML alone. If that distinction matters in your contract, encode it with an attribute such as { "field": { "@nil": "true" } }.
Booleans and numbers are emitted unquoted
Expectedtrue, false, and numeric values render as bare text (<active>true</active>, <amount>19.99</amount>). XML is untyped, so the receiver applies its own schema typing. A JSON string "01234" keeps its leading zero because strings pass through verbatim; a JSON number 1234 does not.
Payload larger than the free limit
Blocked (Pro)JSON to XML is a Pro tool. The free tier caps the input file at 2 MB; Pro raises it to 100 MB. A multi-megabyte SOAP batch payload needs Pro. Conversion still runs locally in the browser either way.
Mixed-type sibling keys you assumed would group
ExpectedThe converter does not reorder or group keys — it serializes them in JSON property order. If your schema requires a specific element order (SOAP sequence types are order-sensitive), arrange the keys in that order in the JSON, because object key order is preserved on output.
Frequently asked questions
How are JSON arrays mapped to XML elements?
An array inside an object repeats under its own key: { "items": ["a", "b"] } produces <items>a</items><items>b</items>. Only a top-level JSON array uses the configurable Array-item element name — a top-level ["a","b"] becomes <root><item>a</item><item>b</item></root>. There is no 'wrap arrays' option that adds a separate plural wrapper element; if you need <Items><Item>...</Item></Items>, shape the JSON as { "Items": { "Item": [...] } } before converting.
Can I emit JSON values as XML attributes instead of child elements?
Yes. Any JSON key starting with the attribute prefix (default @) is emitted as an XML attribute on its parent element — { "@id": "b1" } becomes id="b1". Pair it with the #text key to add element text alongside attributes: { "amount": { "@currency": "USD", "#text": "19.99" } } → <amount currency="USD">19.99</amount>. You can change the prefix in the options if @ collides with your data.
Does the tool generate the SOAP envelope and namespaces for me?
No. It produces the XML for the Body contents only — it does not add a soap:Envelope, soap:Body, or any xmlns declaration. You wrap the converted fragment in your own envelope and add the namespace declarations there (or include them as @xmlns:... keys in the JSON object so they serialize as attributes).
Is there a CDATA option for markup-bearing values?
No CDATA option exists. Instead, the five XML special characters (<, >, &, ", ') in string values are entity-escaped, so <b>bold</b> becomes <b>bold</b>. This is valid XML and the receiving parser decodes it back to the original text — functionally equivalent to CDATA for the receiver, just a different on-the-wire form.
What encoding does the declaration claim?
When the declaration is on, the tool prepends <?xml version="1.0" encoding="UTF-8"?> (UTF-8 is fixed, not configurable). The output string itself is Unicode; UTF-8 bytes are produced when you download the .xml file. SOAP clients should send Content-Type: text/xml; charset=utf-8 for SOAP 1.1.
My root element name became an attribute by mistake — why?
If the attribute prefix is @ and you accidentally named a key @CreateOrderRequest, it is treated as an attribute and won't appear as an element. Element-name keys must not begin with the attribute prefix. Either rename the key or change the attribute prefix to a character your data doesn't use.
How do I represent xsi:nil for an explicitly-null field?
Because both null and "" collapse to <field/>, you can't express xsi:nil from a bare null. Model it explicitly: { "field": { "@xsi:nil": "true" } } serializes to <field xsi:nil="true"/>, and add the xmlns:xsi declaration in your envelope.
Does the order of elements in the output match my JSON?
Yes. Object keys are serialized in JSON property order, so the element order in the XML matches the order in your JSON object. SOAP sequence-typed messages are order-sensitive, so arrange the JSON keys in the schema's required order before converting.
Can I convert a whole SOAP response back to JSON here?
This tool only goes JSON → XML. For the reverse — parsing a SOAP/XML response into JSON, optionally stripping namespace prefixes — use xml-to-json, which has a removeNSPrefix option to drop soap: / ns1: prefixes from element names.
What's the file-size limit for a SOAP batch payload?
JSON to XML is a Pro tool. The free tier accepts inputs up to 2 MB; Pro raises the cap to 100 MB. Everything is processed in your browser, so the practical ceiling on very large payloads is browser memory, not a network or server limit.
Does my request payload leave the browser?
No. Conversion runs entirely client-side. API credentials, order data, and any customer PII in the JSON are never transmitted to JAD Apps servers — only an anonymous run counter is recorded for signed-in dashboard stats, with no payload content.
Can I automate this in a build or integration pipeline?
Yes. The tool runs locally, so you can drive it from the JAD Apps runner against the json-to-xml tool id with the same six options shown above. A common pipeline is: pull JSON from a modern service, convert to the SOAP Body fragment, wrap it in a templated envelope, then POST to the legacy endpoint. For prettifying or minifying the JSON first, chain json-prettifier or json-minifier.
Privacy first
Conversion runs locally in your browser. No file is uploaded — only metadata counters are saved for signed-in dashboard stats.