Convert XML to JSON for REST API Migration

Strip namespaces removes the prefixes that make a SOAP body hard to read. The envelope nesting stays — you unwrap that in your adapter — but the names are now REST-friendly.

Input (captured SOAP body):
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetOrderResponse>
      <Order id="4471"><Total>129.50</Total></Order>
    </GetOrderResponse>
  </soap:Body>
</soap:Envelope>

Options: Strip namespaces ON, Parse attributes ON, Coerce types ON

Output:
{
  "Envelope": {
    "Body": {
      "GetOrderResponse": {
        "Order": { "@id": 4471, "Total": 129.5 }
      }
    }
  }
}

fast-xml-parser collapses repeated siblings into an array, but a single occurrence stays a scalar/object. If your test capture had one line item and production has many, your client code throws on the array. Always capture a multi-record response.

One <Line> (test capture):
<Invoice><Line>A</Line></Invoice>
=> { "Invoice": { "Line": "A" } }       <-- string

Two <Line> (production):
<Invoice><Line>A</Line><Line>B</Line></Invoice>
=> { "Invoice": { "Line": ["A", "B"] } }  <-- array

Migration fix: in the REST adapter, always coerce Line to an
array: const lines = [].concat(invoice.Line ?? []);

SOAP uses attributes for both real data (currency, units) and infrastructure (xsi:type, soap:mustUnderstand). Parse attributes keeps them as @-keys so you can triage; turn it off to drop all of them.

Input:
<Payment amount="40.00" currency="EUR" xsi:type="CardPayment"/>

Parse attributes ON:
{ "Payment": { "@amount": 40, "@currency": "EUR", "@xsi:type": "CardPayment" } }

Parse attributes OFF:
{ "Payment": "" }   <-- attributes gone; empty element => ""

Keep ON, then in the contract: @amount -> amount (number),
@currency -> currency (enum), drop @xsi:type (transport hint).

Legacy SOAP services often stuff a second XML document inside a CDATA block. The tool unwraps CDATA to a plain string in one pass — then you run that string back through the tool to parse the inner document.

Input:
<Resp><Receipt><![CDATA[<r><id>9</id><ok>true</ok></r>]]></Receipt></Resp>

Pass 1 output:
{ "Resp": { "Receipt": "<r><id>9</id><ok>true</ok></r>" } }

Pass 2 (paste the Receipt string back in):
{ "r": { "id": 9, "ok": true } }

Once the shape is clear, hand the JSON to a sibling tool to generate the typed artefacts your REST service needs — no manual transcription of field names.

Workflow:
  1. xml-to-json  (Strip namespaces ON) -> order.json
  2. /tool/json-to-typescript -> Order interface for the Node adapter
  3. /tool/json-schema-generator -> JSON Schema for OpenAPI components
  4. /tool/json-path-extractor -> pull Envelope.Body.*Response to
     drop the envelope wrapper in one expression

There is no 'Unwrap SOAP envelope' toggle in this tool. The converter faithfully preserves structure, so you always get Envelope.Body.<Operation>Response.<data>. Drop the envelope in your adapter, or use json-path-extractor with an expression like $.Envelope.Body to slice it off after conversion.

A response with one <Item> yields Item: {...} (object); two-or-more yield Item: [...] (array). The parser is configured with no forced-array paths, so it cannot know a field is 'always a collection'. Capture a multi-record response, or normalise to an array in your REST client. This is the single most common cause of x.map is not a function after a SOAP→REST cutover.

With Strip namespaces on, <ns1:Id> and <ns2:Id> both become Id. If they are siblings, fast-xml-parser merges them into an array on the Id key — silently mixing two semantically different fields. If prefixes carry meaning in your payload, leave Strip namespaces off and rename in your mapping layer instead.

fast-xml-parser is lenient: a mismatched tag like <a></b> parses without throwing, producing a structurally wrong object rather than an error. Validate your captured XML in a real XML validator first if the source endpoint is flaky — the tool will not flag the corruption for you.

<accountId>007</accountId> becomes the number 7 when Coerce types is on — the leading zeros are gone. SOAP services often use zero-padded reference numbers. Turn Coerce types OFF to keep every value as a string, then selectively cast only the fields you know are numeric in your contract.

A 20-digit transaction ID exceeds JavaScript's safe-integer range. fast-xml-parser detects this and keeps it as a string even with Coerce types on, preventing the precision loss you would get from blind Number(). So <txn>10000000000000000001</txn> stays "10000000000000000001" — correct behaviour for REST contracts.

An element with text interleaved with child tags — <p>See <b>note</b> below</p> — concatenates the text fragments into #text: "Seebelow" with the space dropped. SOAP rarely uses mixed content, but vendor 'description' fields sometimes do. If you hit this, treat the element as opaque HTML at the source rather than relying on the parsed #text.

<wsse:Security> headers (UsernameToken, Timestamp, signatures) are parsed into the JSON like any other element. They are not data you want in a REST contract. Strip them in your adapter or extract only the body with json-key-filter. Because this runs in-browser, the credentials never reach a server — but they are still in the JSON output you copy.

XML to JSON is a Pro tool. You can convert files up to 2 MB on the free tier to evaluate it; signed-in Pro raises the per-file limit to 100 MB. A multi-thousand-record SOAP dump easily exceeds 2 MB, so use a single representative response for design work or upgrade for full batch conversion.