XML to JSON for OIC integration work is most reliably previewed with an in-browser converter that takes one well-formed XML document, applies an explicit object shape, and copies the result without sending the payload to a server. The XML to JSON Converter parses pasted markup with the browser's native XML DOMParser, refuses any DOCTYPE declaration up front, and serializes a deterministic JSON string that you can read alongside an OIC adapter sample. Because the conversion happens entirely client-side, the document never leaves the page, which makes the workflow practical when you are handling configuration snippets, internal endpoint responses, or integration test fixtures that should not travel through a third-party service. That separation between the parsing layer and the receiving OIC mapping is also useful when you are auditing why a payload is being rejected in production: you can reproduce the shape locally without rebuilding the integration, then diff the output against the schema the adapter expects.
Every XML to JSON tool encodes an opinion about how attributes, text, and repeated siblings should be flattened. This one uses an explicit convention rather than claiming to follow a universal standard, and that convention is documented so you can decide whether the output matches the contract your OIC flow expects on the other side. The root element becomes the top-level JSON key, attributes are gathered under a single @attributes object, and direct text inside a structured element is captured under #text. Repeated sibling names become arrays in document order; a single child stays a single value. Namespace prefixes are preserved on element and attribute names, so an element called soap:Body stays "soap:Body" rather than being stripped. None of these choices are inferred — they are part of the converter's contract, and the same XML pasted twice produces byte-identical output, which is what you want when you are comparing reference fixtures.
What Object Shape the Converter Produces
The output is a plain JSON document whose top level mirrors the root element of the XML. Inside that document, four small rules cover almost every payload you will paste from an OIC adapter, an inbound web service, or a sample WSDL message:
- Root as top-level key. The root element name becomes the only top-level field, so a document whose root is <order> produces { "order": ... }.
- Attributes under @attributes. Every attribute on an element is grouped into one object keyed @attributes; the rest of that element's children stay at the same level as ordinary fields.
- Text under #text. A plain text-only element becomes a string. When an element also has attributes or children, the direct text is moved into #text so structural children remain addressable by name.
- Repeated siblings as arrays. Two or more adjacent elements sharing a name collapse into a JSON array in source order; a single occurrence stays as one object or string.
Namespaces are kept as part of the local name, so <ns:customer ns:id="42">Alice</ns:customer> reads as { "ns:customer": { "@attributes": { "ns:id": "42" }, "#text": "Alice" } }. No prefix is dropped, no namespace is promoted to a separate field, and no namespace URI is fetched — the converter does not resolve any external schema, which is the safest behaviour for documents that reference internal-only namespaces that an online tool should not phone home to resolve.
Prepare the XML Document for Conversion
Before you paste anything, strip the document down to a single well-formed payload. Remove any <!DOCTYPE> declaration, because the converter rejects it explicitly to avoid resolving external entities or DTDs. Comments and processing instructions are not carried into JSON, so leaving them in does not change the result, but cleaning the source makes it easier to compare the converted JSON against the original. The browser parser used behind the scenes — described in the MDN DOMParser documentation — follows the rules defined for XML 1.0, so namespace prefixes, CDATA sections, and entity references that resolve to single characters are handled by the parser before the converter walks the tree.
The converter accepts up to 200,000 characters of source per conversion. Anything larger than that should be trimmed, chunked, or routed through a streaming parser in a version-controlled application rather than pasted into a browser field. If your XML came from a minified one-liner or a screen-scraped export and is hard to read, run it through an XML formatter first so you can confirm the structure before the JSON conversion, and so that any line you remove during cleanup is one you can see clearly.
Convert XML to JSON Locally for an OIC Sample
The conversion itself is a short, deliberate sequence. Each step exists because the converter will refuse to guess about malformed input, external resources, or partial output.
- Open the XML to JSON Converter in a new browser tab and read the field-level hints so you know which control changes indentation and which one triggers the conversion.
- Paste one well-formed XML document into the source field. If the document starts with a <!DOCTYPE> line, delete that line and re-check that the remainder still parses as XML.
- Pick an indentation style — compact for a payload you intend to paste into a request body, or four-space indentation when you want the JSON to line up with the XML for review.
- Select Convert to JSON. If the parser reports an error, fix the XML and try again; the converter will not return a partial document for malformed input.
- Inspect the output for the @attributes and #text conventions and confirm that repeated sibling elements turned into JSON arrays in document order.
- Copy the JSON and paste it into your OIC sample, request stub, or test fixture. Nothing has been uploaded — the parsing and serialization happened in the page.
How Specific XML Features Map to JSON
Reading the conversion at a glance is easier when you know exactly what each XML construct becomes. The table below summarizes the convention for the cases that show up most often in OIC adapter samples.
| XML construct | JSON representation | Notes |
|---|---|---|
| Element with only attributes | Object with @attributes only | No #text field is added when there is no character data. |
| Empty element <tag/> | Empty string "" | If attributes exist, they appear under @attributes and the element has no string value. |
| CDATA section | Contributes to #text | CDATA text is treated as character data; delimiters are not preserved. |
| Comments and processing instructions | Dropped | They never appear in the JSON output. |
| Repeated sibling elements | Array in source order | Order matters and is preserved exactly. |
| Single sibling element | Single value, not an array | A one-off element is never wrapped in a one-element array. |
| Mixed content (text plus children) | #text plus named children | Exact interleaving between text and children is not preserved. |
| Namespace-prefixed names | Kept verbatim | Prefix and local name are joined with a colon in the field name. |
The key point for OIC preparation work is that nothing is silently rewritten from one JSON type to another. An identifier such as 007 stays the string "007"; a postal code such as 01234 does not become the integer 1234; a true/false text value in XML is not coerced into a JSON boolean. This lexical discipline is intentional, because XML has no standard for typing text and most receiving systems depend on the original string for IDs, code lists, and reference numbers.
When the Converter Is the Wrong Tool
The browser workflow is a sharp instrument for small, well-bounded conversions, and it is not a substitute for a full XML pipeline. The table below contrasts the cases where the in-browser converter is the right choice with the cases that belong in a version-controlled parser, schema validator, or ETL job that ships with your integration code.
| Use the browser converter when | Use a version-controlled parser when |
|---|---|
| The document is under the 200,000-character input cap | The document routinely exceeds the cap or streams in over time |
| You only need the structural shape for review or test data | You must validate against an XSD, Schematron, or business rule |
| The XML is bounded by your team or generated by a known source | The XML comes from untrusted external systems and needs sanitization |
| Lossless mixed-content preservation is not required | The receiving system demands exact text-versus-element ordering |
| You want a deterministic reference output to compare with an OIC mapping | You need a test-covered conversion path that runs unattended |
If any of the right-column cases apply, the same XML still belongs in your project, but it should be processed by a library whose behaviour you control, and the converter output should be used as a reference shape for tests rather than as the production path. The XML to JSON Converter never fetches schemas, DTDs, external entities, namespaces, stylesheets, or remote resources, so even when it is the wrong tool, it is also not a tool that quietly performs network calls on your behalf.
Validate the JSON Against the Receiving System
Once the JSON is in hand, run it through a JSON validator to catch any structural slips and, if readability is what you need next, hand the same document to a JSON formatter to pretty-print it before you compare fields against an OIC mapper. The browser parser and the converter can both succeed while still producing a shape that does not match what your integration expects, so a final visual review of @attributes, #text, and array boundaries is part of the workflow rather than an optional step. When you do spot a mismatch — for example, a receiving system that requires every repeated child to be an array even when only one occurrence is present — adjust the convention in your own mapping layer rather than expecting the converter to bend to every schema it meets.
For a deeper look, see Convert CSV to HTML Table in JavaScript: A Safe Workflow.
For a deeper look, see How to Convert Excel to JSON Outside the GST Offline Tool.