JSON to XML Converter
Convert JSON data to XML format instantly. Paste text or upload a .json file.
No data sent to serverRelated Tools
What is JSON to XML?
JSON dominates modern web APIs (REST, GraphQL); XML still powers enterprise systems (SOAP web services, financial protocols, government standards, Android/Java configs). Converting JSON → XML is needed for integration scenarios where one side speaks JSON and the other requires XML.
Common scenarios: SOAP integration (legacy enterprise APIs), Android manifest generation, Maven / Gradle build files, RSS / Atom feed creation, SVG generation from data, OFX/HL7 medical/financial standards, plist files (iOS/macOS configurations).
Conversion example
# JSON
{
"user": {
"name": "Alice",
"age": 30,
"hobbies": ["reading", "coding"]
}
}
# XML
<?xml version="1.0" encoding="UTF-8"?>
<root>
<user>
<name>Alice</name>
<age>30</age>
<hobbies>reading</hobbies>
<hobbies>coding</hobbies>
</user>
</root>JSON vs XML — historical context
- XML (1998) dominated APIs in the early-to-mid 2000s — SOAP, RSS, AJAX (X = XML originally)
- JSON rose in the late 2000s — simpler syntax, native to JavaScript, less verbose
- 2010+: most new public APIs are JSON; XML survives in enterprise/government/legacy
- 2026: ~95% of web APIs are JSON. XML is reserved for specific domains (SOAP, RSS, configuration formats, document standards like DOCX/ODT internally)
Conversion challenges
- JSON has no element name — XML needs a root element name (this tool uses
<root>) - JSON arrays become repeated XML elements with the same tag
- JSON keys become XML element names — must be valid XML (no spaces, no leading numbers)
- XML attributes vs elements — JSON has no attribute concept; conversion produces elements only
- Special characters —
<,>,&must be escaped as<, etc.
How to Use
- Paste JSON data, or upload a
.jsonfile. - Click Convert.
- Review XML — verify element nesting and array handling.
- Copy or download as
.xml.
Going Back to the Older Standard
Most new systems speak JSON, so converting the other way is usually driven by something that will not change: an enterprise integration, a SOAP endpoint, a government or banking interface, an industry data standard, or a legacy application that predates JSON entirely.
The direction is easier than XML to JSON, because JSON’s model is simpler and everything in it has a natural XML representation. The complications are about naming rather than structure.
Naming Rules That JSON Does Not Have
JSON property names can be almost anything — spaces, hyphens, digits at the start, emoji. XML element names cannot. They must begin with a letter or underscore, cannot contain spaces, and cannot start with the letters “xml” in any casing.
So a property called first name or 2024-total has to be transformed into something legal, and that transformation is not reversible without knowing the rule that was applied.
Arrays raise a second question. JSON has a real array type; XML expresses lists by simply repeating an element. That means an empty array has no representation at all, and a converted document loses the distinction between “no items” and “the field was absent”.
If the XML has to match a specific schema, expect to adjust the output rather than use it directly — a general converter cannot know your element naming conventions.
FAQ
How are arrays converted?
JSON arrays become repeated XML elements with the same tag name. “hobbies”: [“reading”, “coding”] → <hobbies>reading</hobbies><hobbies>coding</hobbies>. This is the standard XML idiom for collections.
Is the XML declaration included?
Yes — output starts with <?xml version="1.0" encoding="UTF-8"?>. Required for strict XML parsers.
What if my JSON has keys with spaces or special characters?
XML element names can’t contain spaces or start with numbers. Such keys produce invalid XML — rename them in JSON first (e.g., “first name” → “first_name”) before converting.
Can I produce XML attributes instead of elements?
Not directly — JSON has no attribute concept. For SOAP/specific schemas needing attributes, use a library like xml-js with custom mapping rules.
Why use XML in 2026?
Mostly legacy / domain-specific: SOAP services in finance/government, RSS/Atom feeds, document formats (DOCX/EPUB use XML internally), Android/Java configs (AndroidManifest.xml, pom.xml), HL7 medical messaging. New systems almost always use JSON.
What happens to property names with spaces or hyphens?
They are transformed into valid XML element names, because XML forbids spaces and has strict rules about the first character. The original name cannot always be recovered from the result.
How are arrays represented?
As repeated elements, which is the XML convention. An empty array produces nothing, since there is no element to repeat.
Will the output validate against my schema?
Not necessarily. A general converter cannot know your required element names, ordering, or namespaces. Treat the output as a starting point for schema-specific work.
Are special characters escaped?
Yes. Ampersands, angle brackets, and quotes are escaped so the result is well-formed XML.
Are null values represented?
JSON null has no direct XML equivalent. It typically becomes an empty element, which means the distinction between null and an empty string does not survive the round trip.
Can I add a namespace to the output?
Not automatically — namespaces depend on the schema you are targeting, which a general converter cannot infer. Add the declaration to the root element afterwards if your consumer requires one.
⚠️ Reference Only
Output is generated based on your input and is provided for reference. Results may vary depending on your specific use case, edge cases, or environment-specific behavior. We do not guarantee accuracy of conversions, validations, or computed values.
Always verify critical outputs against official documentation or production environments. We are not responsible for any decisions or losses based on these tool results.