How to Convert XML to JSON Online

Converting XML to JSON is one of those tasks that sounds simple until you encounter a real-world document: attributes mixed with element content, nested namespaces, CDATA sections, or mixed text and child nodes. The Koodisi XML to JSON Converter handles all of it automatically — paste your document, click Convert, and get clean, structured JSON output ready to use in your code.

The conversion workflow is three steps:

Paste XML. Copy your XML document — an API response, a SOAP envelope, an RSS feed, a config file, or any well-formed XML — and paste it into the input field. The converter accepts any valid XML regardless of depth, namespace usage, or schema.
Convert. Click Convert. Element names become JSON keys, element text content becomes string values, child elements become nested objects, repeated elements of the same name become arrays, and XML attributes are mapped to prefixed keys in the corresponding JSON object. The converter preserves the full semantic structure of the original document.
Copy or download. Copy the JSON output to your clipboard with one click, or download it as a .json file for use in your project, pipeline, or integration workflow. The output is pretty-printed with standard 2-space indentation for immediate readability.

Everything runs in the browser. Your XML is never sent to a server, so you can safely convert internal SOAP responses, ERP exports containing sensitive business data, or XML files that include credentials or PII.

What Is XML and Why Convert It to JSON?

XML (Extensible Markup Language) is a text-based format for encoding structured data. It was standardized by the W3C in 1998 and quickly became the dominant interchange format for enterprise systems, web services, and configuration files through the 2000s. SOAP-based web services, EDI transactions, RSS and Atom feeds, SVG graphics, Microsoft Office documents (OOXML), and countless ERP and CRM exports all use XML as their native format.

Despite its age, XML remains deeply embedded in enterprise software. Systems like SAP, Oracle EBS, Salesforce (SOAP API), and countless legacy SFTP-based data feeds still produce XML output. If you're building integrations that touch these systems, you will encounter XML — often a lot of it.

The problem is that most modern development tooling, REST APIs, and frontend frameworks prefer JSON. JSON is:

Native to JavaScript. Browsers can parse JSON without a library. JSON.parse() is built into every JavaScript runtime.
More concise. JSON typically produces smaller documents than equivalent XML because it has no closing tags.
Easier to work with in code. Accessing a nested field in JSON is data.user.address.city; the XML equivalent requires DOM traversal or XPath queries.
Better supported in modern APIs. The overwhelming majority of REST APIs, serverless functions, and cloud services consume and produce JSON natively.

Converting XML to JSON is the bridge between the legacy world and the modern one. It lets you consume XML data from an enterprise system or legacy API and feed it into a REST-native workflow, a JavaScript application, or a data pipeline — without writing a custom parser or dealing with XML DOM APIs.

How XML Attributes and Elements Map to JSON

The trickiest part of XML-to-JSON conversion is handling attributes. XML elements can carry both attributes (metadata about the element) and child content. JSON has no native concept of an attribute — everything is a key-value pair. The converter needs a consistent convention to represent both.

Consider this XML:

<user id="42" active="true">
  <name>Alice</name>
  <email>[email protected]</email>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
</user>

The Koodisi converter maps it to JSON using a predictable set of rules:

Element names become JSON keys. <user> becomes the top-level key "user".
Attributes are prefixed with @. The id and active attributes on <user> become "@id" and "@active" keys inside the user object. This convention (popularized by tools like Badgerfish and the xml2js library) clearly distinguishes attribute-derived keys from element-derived keys.
Text content is stored under #text. When an element has both attributes (or child elements) and text content, the text goes into a "#text" key to avoid ambiguity.
Repeated elements become arrays. The two <role> elements inside <roles> become a JSON array ["admin", "editor"] rather than two separate keys.

The resulting JSON:

{
  "user": {
    "@id": "42",
    "@active": "true",
    "name": "Alice",
    "email": "[email protected]",
    "roles": {
      "role": [
        "admin",
        "editor"
      ]
    }
  }
}

This structure is predictable, reversible, and compatible with the output format expected by most XML-to-JSON libraries — which means you can use the converter's output directly in code that relies on xml2js, fast-xml-parser, or similar tools.

XML vs JSON: When to Use Each Format

Despite JSON's dominance in modern APIs, XML has genuine strengths that make it the right choice in certain contexts. Understanding when each format excels helps you decide when conversion is appropriate and when it might lose important information.

Where XML excels

Namespaces. XML has a first-class namespace system that lets you combine elements from multiple schemas in a single document without name collisions. SOAP envelopes, for example, use namespaces to distinguish the SOAP envelope structure from the message payload. JSON has no equivalent concept.
Document validation with DTD and XSD. XML supports rich schema validation via Document Type Definitions (DTD) and XML Schema Definition (XSD), including type constraints, cardinality, and relationship validation. JSON Schema is catching up, but XSD remains more expressive for complex document structures.
Mixed content. XML handles documents where elements contain both child elements and text — like an HTML paragraph that contains both text and inline tags. JSON has no clean equivalent.
SOAP and WS-* protocols. Enterprise middleware standards like SOAP, WS-Security, and BPEL are built on XML and cannot be translated to JSON without losing protocol-level semantics.

Where JSON excels

REST APIs. JSON is the lingua franca of REST. Every major API platform, cloud provider, and SaaS tool defaults to JSON for its REST API.
Browser and JavaScript environments. JSON parses natively, serializes natively, and maps directly to JavaScript objects. Working with XML in the browser requires the DOMParser API or third-party libraries.
Readability. JSON is easier for humans to read and write than XML, with less syntactic noise (no closing tags, no angle brackets).
Streaming and NoSQL databases. Systems like MongoDB, DynamoDB, Elasticsearch, and most event streaming platforms store and query JSON natively.

The practical conclusion: if you control both ends of the wire, use JSON. If you're consuming data from a system you don't control — a legacy ERP, a SOAP service, an SFTP feed — convert XML to JSON at the boundary and work in JSON from that point forward. That's exactly the pattern Koodisi's integration pipelines follow.

XML to JSON Conversion Use Cases

Knowing when and why to convert XML to JSON is as important as knowing how. Here are the most common scenarios where integration developers reach for an XML-to-JSON converter:

SOAP to REST Migration

Many enterprise systems expose SOAP APIs that predate the REST era. When building a modern integration that consumes a SOAP service, the first step is typically converting the SOAP response (an XML envelope) to JSON so downstream processing can work with standard JavaScript or Python objects. The converter handles the SOAP envelope structure, stripping the boilerplate and exposing the actual payload as clean JSON.

Legacy ERP Integration

ERP systems like SAP, Oracle EBS, and Microsoft Dynamics often produce XML exports — either as flat file extracts or as responses from their proprietary API layers. Converting these exports to JSON makes them compatible with modern ETL pipelines, cloud data warehouses, and REST-based integration platforms.

RSS and Atom Feed Processing

RSS and Atom are XML-based syndication formats. If you're building a content aggregator, a news monitoring tool, or a social listening integration, converting RSS feeds to JSON lets you process them with the same code you use for REST API responses.

Salesforce XML Exports

Salesforce's SOAP API and many of its bulk data export formats produce XML. When integrating Salesforce with a modern data pipeline or a REST-native target system, converting the XML output to JSON is a standard first step.

Configuration File Normalization

Some build tools, application servers (Tomcat, JBoss), and CI systems use XML configuration files. When you need to compare, merge, or programmatically modify these configs, converting to JSON makes them easier to handle with standard scripting tools.

Handling XML Namespaces in JSON Conversion

XML namespaces are one of the trickiest aspects of XML-to-JSON conversion. A namespace declaration like xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" attaches a URI to a prefix, which is then used to qualify element and attribute names. The purpose is to prevent name collisions when combining elements from multiple schemas in a single document.

Consider a typical SOAP envelope:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soap:Body>
    <GetOrderResponse>
      <OrderId xsi:type="xsd:string">ORD-12345</OrderId>
      <Status>shipped</Status>
    </GetOrderResponse>
  </soap:Body>
</soap:Envelope>

The Koodisi converter preserves namespace prefixes in JSON key names — soap:Envelope becomes the key "soap:Envelope", and namespace declarations (xmlns:soap) are represented as "@xmlns:soap" attributes on the enclosing object. This ensures the JSON output is a lossless representation of the original XML, which matters when you need to convert back or when downstream code needs to understand the provenance of a field.

If you're processing the JSON in a context where namespace prefixes are irrelevant — because you only care about the payload fields and not the envelope metadata — you can strip or ignore the namespace-related keys after conversion. The converter gives you the full picture; your application code decides how much of it to use.

XML to JSON in Enterprise Integration Pipelines

For one-off conversions, the browser-based converter is the fastest path. But in production integration workflows that process XML data at scale — polling an SFTP server for daily ERP exports, subscribing to a SOAP event feed, transforming batch XML files before loading to a data warehouse — you need conversion baked into the pipeline itself, not handled manually.

Koodisi is an integration platform built for exactly this kind of workflow. Its transformation capabilities handle XML-to-JSON conversion as a native pipeline step: connect to the XML source (SFTP, SOAP endpoint, S3 bucket, FTP feed), apply the transformation, and route the resulting JSON to any downstream target — a REST API, a database, a message queue, or another integration workflow.

The browser-based converter on this page is a companion tool for the development and debugging phase: understand what the XML looks like, verify that the conversion produces the JSON shape your downstream code expects, and test edge cases before committing to a pipeline configuration. Use the Diff Viewer to compare the JSON output of two similar XML documents when you're mapping fields and need to understand which fields vary between records.

When you're ready to go the other direction — from JSON back to XML — the JSON to XML converter handles the reverse transformation with the same conventions.

Frequently Asked Questions

How are XML attributes handled in the JSON output?: XML attributes are converted to JSON keys prefixed with @. For example, an element <user id="42"> produces a JSON object with an "@id": "42" key alongside any child-element-derived keys. This convention is consistent with widely-used XML parsing libraries and makes it easy to distinguish attribute-derived data from element-derived data in your code.
Does the converter handle CDATA sections?: Yes. CDATA sections (<![CDATA[ ... ]]>) are treated as text content. The raw text inside the CDATA block is extracted and stored as the string value of the corresponding JSON key — the CDATA wrapper is stripped. This means HTML or other markup embedded in a CDATA section is preserved as a plain string in the JSON output.
What happens to XML namespaces?: Namespace prefixes are preserved in JSON key names (e.g., soap:Body becomes the key "soap:Body"), and namespace declarations are represented as @xmlns keys. This ensures a lossless round-trip representation. If you don't need namespace information in your downstream processing, you can strip those keys after conversion.
Can it handle large XML files?: The converter runs in the browser, so performance is limited by available browser memory and JavaScript engine speed. Typical developer payloads — API responses, config files, ERP record extracts — convert instantly. Very large XML files (multiple megabytes or deeply nested structures with thousands of nodes) may be slow. For production-scale batch conversion, Koodisi's integration platform handles XML transformation natively as a pipeline step.
Can I convert JSON back to XML?: Yes, using the JSON to XML converter. It applies the same conventions in reverse — @-prefixed keys become XML attributes, #text keys become text content, and arrays become repeated elements of the same name. The round-trip fidelity is high for documents that originated as XML.

XML to JSON

We're building this