Free JSON to XML Converter

JSON and XML, Two Formats, Two Eras

XML (Extensible Markup Language) was standardised by the W3C as a Recommendation on 10 February 1998, the W3C XML 1.0 spec, edited by Tim Bray, Jean Paoli and C.M. Sperberg-McQueen. XML grew out of SGML (the older "Standard Generalised Markup Language", ISO 8879:1986) by stripping out the most complex features and producing something the web could realistically use. For roughly the first decade of the 21st century, XML was the assumed format for any structured data exchange, SOAP web services, RSS feeds (RSS 2.0, Dave Winer, 2002), Atom (RFC 4287, 2005), Microsoft Office's Open XML formats (.docx/.xlsx/.pptx, ISO/IEC 29500:2008), Android XML layouts, Java property files, configuration in nearly every server framework. XML's strengths are namespaces, attributes, mixed content (text and child elements interleaved), and a rich schema ecosystem (DTD, XML Schema 1.1, Relax NG). Its weakness is verbosity, every value carries an open and close tag.

JSON (JavaScript Object Notation) was specified by Douglas Crockford in 2001, the json.org website and his original "JSON: The Fat-Free Alternative to XML" essay. JSON is intentionally a subset of JavaScript object literal syntax: objects, arrays, strings, numbers, true/false/null. Standardised as RFC 4627 in July 2006, refined as RFC 7159 (March 2014) and RFC 8259 (December 2017, current STD 90 standard, also published by ECMA as ECMA-404). JSON's takeover of web APIs from XML happened roughly 2008-2014, the timing matches the rise of single-page apps and the mobile API era. Today nearly every public API documents itself as JSON; XML mostly survives in enterprise integration, document formats, configuration files, and feed formats. The two formats remain in active use because they encode different things well: JSON is right for structured data with simple types and predictable shape; XML is right for documents with mixed content, attributes, namespaces and rigorous schemas.

When You Actually Need to Convert JSON to XML

• Calling a SOAP web service from a JSON-only client. SOAP is XML-based by design (the SOAP envelope, the WSDL service description, the XSD schemas). If you have data in JSON form and need to construct a SOAP request body, JSON-to-XML is the bridge. Common in enterprise integration when modern microservices need to talk to legacy SOAP endpoints (banking, government, insurance, healthcare interchange systems).
• Generating Office Open XML documents from JSON data. The .docx, .xlsx and .pptx formats are ZIP archives of XML files. To programmatically generate or modify Office documents from JSON-backed data, the JSON-to-XML conversion happens at the boundary between your application's data layer and the document generation library.
• Producing an RSS or Atom feed from JSON content. Blogs, news sites and podcast platforms emit RSS/Atom feeds for syndication. If your CMS stores articles as JSON, the feed-generation step converts JSON entries into the XML format the feed-reader ecosystem expects.
• Generating XML configuration files for legacy applications. Many older enterprise applications (Java application servers, .NET configuration files, Spring XML application context) consume their configuration as XML. Modern infrastructure-as-code tooling typically works in YAML or JSON, so a JSON-to-XML conversion sits in the deployment pipeline.
• Feeding data into an XSLT transformation. XSLT (XSL Transformations, Michael Kay's specification, W3C Recommendation) is the standard XML transformation language and consumes XML input. If your data starts in JSON and your reporting engine is XSLT-based, the conversion happens at the input boundary.
• Generating Android resource files. Android's strings.xml, colors.xml, dimens.xml and layout files are XML. Localisation pipelines that store strings in JSON for ease of editing convert to XML at build time.

The Conversion Mapping, Where Information Survives and Where It Loses

JSON and XML have different structural primitives, so any conversion must make choices. The standard JSON-to-XML mapping that most converters (this one included) follow:

• JSON objects become XML elements. Each key becomes a child element with the key as the tag name. {"name": "Alice"} becomes <name>Alice</name>.
• JSON arrays become repeated child elements. {"items": [1, 2, 3]} becomes three <item>1</item><item>2</item><item>3</item> children inside the <items> wrapper. (Different converters use different conventions for the array-element name; some use the parent's name singularised, some use a fixed <item>.)
• Strings, numbers, booleans become text content of the element. Type information is not preserved, XML treats all text as character data, so a roundtrip XML → parse → serialise back to JSON would emit numbers as quoted strings unless the consumer applies type inference.
• null becomes a self-closing empty element. {"middle_name": null} becomes <middle_name/>. Some converters use xsi:nil="true" instead.
• The root element wraps everything. JSON allows a top-level array or scalar; XML requires exactly one root element. The <root> wrapper (configurable here) is the conventional fix.

Information lost in the conversion: JSON's distinction between numbers and strings, JSON's distinction between true/false and "true"/"false" strings, JSON's array vs object distinction (when an array becomes repeated elements you can't tell from the XML alone whether the source had a one-element array or a single value). Information potentially gained but not used by simple converters: XML attributes (a JSON object could map keys to attributes rather than child elements), XML namespaces (JSON has nothing equivalent), CDATA sections (for embedding text with XML special characters). For a roundtrip-safe JSON-to-XML conversion that preserves type information, the BadgerFish convention or the Parker convention encode JSON types as namespaced XML attributes, this tool produces the simpler, more readable form rather than the roundtrip-safe form.

XML Tag-Name Constraints That JSON Keys Don't Have

JSON object keys are arbitrary strings, any Unicode is allowed. XML element names are far more restricted: they must start with a letter or underscore (not a digit, hyphen or period), can contain letters, digits, hyphens, underscores and periods (no spaces, no most punctuation), are case-sensitive, and cannot start with the reserved prefix xml in any case combination. JSON keys with spaces ("first name": "Alice"), keys starting with digits ("3rd_choice"), or keys with special characters ("@type", "$value") cannot be used as XML element names directly. Most converters (this one included) silently mangle invalid characters, replace spaces with underscores, prepend an underscore to keys starting with digits, drop most punctuation. Be aware of this when round-tripping: a JSON document with non-XML-safe keys won't round-trip identically through XML.

Where XML Still Reigns in 2026

XML is not in retreat in 2026, it's just settled into specific niches. Document formats: Office Open XML (Microsoft Office), OpenDocument (LibreOffice), EPUB ebooks, SVG (W3C Recommendation 4 September 2001), MathML, XHTML. Configuration: Java application servers, Spring XML contexts, Maven POMs, Android XML resources, .NET app.config and web.config files. Feeds: RSS 2.0, Atom 1.0 (RFC 4287), podcast feeds (the iTunes RSS extensions). Healthcare and government interchange: HL7 v3, FHIR (which now offers JSON as an alternative but the XML form remains in heavy use), DocBook, NewsML, banking ISO 20022. Standards bodies: Almost every IETF and W3C specification example uses XML. XML's verbosity is a feature in those domains: it's self-describing, validating against a schema is well-established, and XSLT transformations between XML dialects are a mature toolkit. The format isn't going anywhere; the JSON-to-XML conversion is the bridge between modern data tooling and these established XML-native systems.

Privacy: Browser-Only Conversion

JSON pasted into a converter often contains real production data, API responses with user identifiers, internal entity IDs that reveal business taxonomy, configuration values that include endpoint URLs and feature flags, tokens, draft content not yet published. Server-side converters take a copy of every input into their logs. This converter parses your JSON with the browser's built-in JSON.parse(), walks the resulting object tree in JavaScript, and emits XML as a string, all inside your browser tab. Verify in DevTools' Network tab while you click Convert (no requests fire), or take the page offline (airplane mode) after it loads and the converter still works. Safe for production API responses, internal config, draft content, or any JSON you wouldn't want copied onto a stranger's hard drive.

Frequently Asked Questions

How are JSON arrays converted?

Each array element becomes a separate child element. {"colors": ["red", "blue"]} becomes <colors><item>red</item><item>blue</item></colors>. The conventional element name for unnamed array entries is <item>. If your downstream consumer expects a different convention (e.g., singular form of the parent name like <color>), you'll need to post-process the XML or use a different converter that supports custom array-element naming.

Does this work with large JSON files?

Yes, because everything runs in your browser, the practical ceiling is your device's available memory. Tens of thousands of lines of JSON convert in well under a second on a modern laptop. Very large inputs (multi-MB) may briefly freeze the tab while the parser walks the tree. For batch conversion of large datasets, a script using a server-side converter (xml2js in Node, dicttoxml in Python) is more appropriate.

Is my JSON uploaded to a server?

No. Conversion runs entirely in your browser, pasted JSON never leaves your device. Verify in DevTools' Network tab while you click Convert (no requests fire), or take the page offline (airplane mode) after it loads. Safe for production API responses, internal configuration, or any data you wouldn't want shared externally.

Can I make some JSON keys become XML attributes instead of child elements?

This converter emits all JSON keys as child elements, not attributes. The convention some converters use (keys prefixed with @ become attributes ("@id": 5 → id="5" on the parent)) is the BadgerFish convention. If your downstream consumer requires specific values as attributes, you'll need a custom converter that understands the convention, or hand-edit the resulting XML.

What happens to JSON keys that contain spaces or invalid XML characters?

XML element names have stricter rules than JSON keys: they must start with a letter or underscore, can't contain spaces, and disallow most punctuation. Keys with invalid characters get sanitised, spaces become underscores, leading digits get an underscore prefix, special characters are dropped. This means a round-trip JSON → XML → JSON may not produce the original key names exactly. If your data has unusual keys, inspect the output to make sure the mangling didn't break anything important.

Related Tools