JSON to XML Converter

1. 1

   Paste or drop your JSON

   Paste JSON into the box, or drop a .json, .jsonl, .ndjson, .geojson or .txt file. JSON Lines is detected on its own — you do not have to switch a mode.

2. 2

   Name the root and the repeated elements

   Set the top-level element (root by default). Choose whether an array's items are all named item, named after the key the array hung from, or after the singular of that key — so books becomes book.

3. 3

   Decide how values are written

   Choose what a null becomes: an empty element, xsi:nil, or nothing at all. Turn on attribute mapping if your keys use the @name and #text convention. Pick an indent, a declaration and an output encoding.

4. 4

   Convert, then download or copy

   Press Convert to XML. The document preview updates as you change settings, so you can see the shape before you export. Download the .xml, copy it, or generate a matching .xsd schema.

This free converter turns JSON into well-formed XML on your device. Paste or drop a file, name the root element and the repeated elements an array produces, decide what a null and an unusable key become, and export. The document preview updates as you change settings, so you can see the shape before you commit to it. Invalid JSON shows the problem, its line and column, and a snippet — plus links to the JSON Formatter and Validator.

• Root element — The top-level tag that wraps the document — root, data, response, anything that is a legal XML name. A name that is not legal is repaired and the change is shown to you rather than applied silently.
• Array item naming — A fixed tag for every array, or the key the array hung from, or the singular of that key — so a books array writes book elements, which is what a person would have written by hand.
• Attributes and text — Turn on the @name and #text convention and a key written @id becomes an XML attribute while #text becomes the element's own text. This is the exact round-trip partner of the XML to JSON tool.
• Null, empty and missing — A JSON null can be an empty element, an xsi:nil element a schema can read, or nothing at all. Three genuinely different meanings, and most converters offer one.
• Error detail — Invalid JSON shows the message, the line and column, and a snippet with the position marked. Duplicate keys are reported as well, because they are legal and ambiguous.

JSON has six kinds of value and XML has elements, attributes and text. The mapping is direct, and the only decisions are the ones the settings expose.

• Objects become nested elements — Each key becomes a child element named after it, in the order the keys appear in the source.
• Arrays become repeated elements — An array does not become one element with a list inside it; it becomes the same element written once per item, which is how XML has always spelled a repeated value.
• Strings, numbers and booleans become text — There is no XML type for any of them, so each is written as the element's text content. Turn on type annotations and each element also carries type="number", type="string" or type="boolean".
• Numbers are copied, not recalculated — The digits you wrote are the digits that come out. A twenty-digit id stays exact, -0 stays -0, and 1e-7 stays 1e-7 — none of which survives a trip through a floating-point value.
• The root has to be invented — JSON can have an array or even a bare string at the top level; XML must have exactly one root element. That is what the root element setting names.

This is the single thing most JSON to XML converters get wrong, and it is invisible in the output. XML has no way to mark whitespace as decorative — every character between an element's tags is part of its value. So an element whose content is text cannot be indented without changing what it says.

• The failure — Written naively, the array ["a","b"] pretty-prints to an item element with a newline before the a and a newline and two spaces after it. Read back by any conformant parser, that value is not "a" — it is a newline, an a, a newline and two spaces.
• The consequence — Turning pretty-print on changes the data, and the compact output and the indented output of the same converter disagree about what the document means. Nothing errors and nothing looks wrong.
• The rule here — Whitespace is added inside an element only when every one of its children is another element. An element holding any text at all is written on one line, at every indent setting. Round-tripping the output through two independent XML parsers is part of this tool's test suite.

JSON has no attributes, so a converter needs a convention to produce them. This tool uses the one that XML-to-JSON libraries already speak: a key beginning with @ becomes an attribute of the containing element, and the key #text becomes the element's text content. It is off by default, because those are keys your data may legitimately use.

• What it produces — {"@id": "7", "name": "Ada"} becomes an element carrying id="7" with a name child, rather than two child elements one of which is called _id.
• Round trips — This is the convention the XML to JSON tool on this site reads, so a document converted one way and back comes out the same shape.
• When a value cannot be an attribute — An attribute holds flat text. An object or array under an @key is written as an ordinary child element instead — never dropped, never stringified into a JSON blob inside your XML — and the count is shown.
• Mixed content — If an element ends up with both text and child elements, the whole element is written on one line. That is the only way to keep the text exactly as it was; see the section above.

JSON keys are arbitrary strings. XML element names are not: they must start with a letter or underscore, may not contain spaces or most punctuation, and may not begin with the letters xml in any case. Something has to give, and how it gives is a setting rather than a silent decision.

• Repair, and show the list — "first name" becomes first_name and "2024" becomes _2024. A leading digit is prefixed rather than deleted, so 2024 and 024 do not collapse into the same name. Every rename is listed in the panel beside the preview.
• Or keep the original text — The other option writes a key element carrying name="first name", so the original string survives verbatim in the document. Uglier, lossless, and what this page produced before it was rebuilt.
• Accents and non-Latin scripts are kept — Führung, señor and 名前 are all perfectly legal XML element names and are written exactly as they are. Converters that strip anything outside A–Z mangle the column names of most non-English exports without saying so.
• Collisions are separated — If "first name" and "first-name" both repair to first_name, the second becomes first_name_2 — merging them would be data loss that reads as success. A key that was already legal always keeps its own name.
• Emoji become an underscore, deliberately — The XML specification allows them; real parsers do not agree. One strict parser refuses a document with an emoji element name outright and another silently discards the element and its contents. An underscore reads back identically everywhere.

"No value" has several meanings in JSON and several spellings in XML, and choosing between them is the difference between a document a schema can validate and one it cannot.

• An empty element — The default. A null becomes an element with nothing in it, which is the shape most consumers expect.
• xsi:nil — Writes the element as nil, and declares the schema-instance namespace on the root. This is the only spelling a consumer can tell apart from "the exporter forgot this field", and it is what an XSD expects.
• Omitted — The element is not written at all. This applies to object members only — an array item that is null is still written, because an array's length is data and dropping an item silently shifts every index after it.
• Empty objects and arrays — Both become an empty element. An empty array does not produce a blank line inside a pair of tags, which is what a naive writer emits.

Every competing converter writes item for every array in the document, which loses the one piece of information the array carried: what its contents were. Three options here, and the third is the one nobody else offers.

• A fixed tag — Every array item gets the tag you type — item by default. Predictable, and what a consumer written against another converter will expect.
• The parent key — Items are named after the key the array hung from, so a books array produces books elements inside a books element.
• The singular of the parent key — books produces book, categories produces category, children produces child. This is what a person writing the XML by hand would have written. Where the word cannot be shortened, the fixed tag is used instead rather than nesting a name inside itself.
• A root-level array — An array at the very top of the document has no key to be named after, so the root element's name is used as the parent instead.

The three settings that decide what the file looks like rather than what it says. The encoding one is worth reading: it is the setting most often implemented as a label rather than as a fact.

• The XML declaration — On by default. It states the version and the encoding, and a consumer that reads the declaration will believe it — which is why the bytes have to match it.
• Indentation — Two spaces, four spaces, tabs, or none at all. None produces the whole document on one line, which is what you want when the consumer is a program rather than a person.
• UTF-8 — The default, and the right answer almost always. Written without a byte-order mark, because the declaration already says so and a mark breaks consumers that expect the file to start with a bracket.
• UTF-16 — Written as real UTF-16 bytes with a byte-order mark, because a UTF-16 document without one is not reliably detectable and several parsers refuse it.
• ISO-8859-1 — Genuinely encoded as Latin-1. Every character the encoding cannot hold is written as a numeric character reference first, which is legal XML and loses nothing — so a document that says ISO-8859-1 really is one. A converter that writes the label and emits UTF-8 anyway produces a file that is wrong in a way no validator catches.

One JSON value per line, with no wrapping array. It is what log pipelines, bulk API exports and data-warehouse dumps emit, and the standard JSON parser refuses it outright — so most converters simply cannot open the files people most often have.

• Detected, not switched on — Drop a .jsonl or .ndjson file and it is recognised. A .json or .txt file that turns out to hold one value per line is recognised too, because the extension is a hint rather than a promise.
• What it produces — Each line becomes one repeated element under the root, exactly as if the lines had been an array. Every array setting applies as usual.
• Blank lines are ignored — A trailing newline at the end of a file is universal and is not a mistake. Any other line that is not valid JSON reports the line number, which is the only coordinate that means anything in this format.

JSON has no schema, so an XSD has to be induced from the document itself. This one is collected while the XML is being written rather than by a second pass over the JSON, which means it can only ever describe elements that were genuinely produced, with the names they were genuinely given.

• Cardinality comes from the data — A child element missing from any one instance of its parent is marked optional. A child seen more than once in any single instance is marked unbounded.
• Types are narrowed only when they are certain — An element is an integer type only when every value seen was integral in the source text — including values too long to survive as a floating-point number. One decimal anywhere widens it.
• Ambiguity widens rather than guesses — An element seen with both text and children is marked mixed; one seen as both a container and a scalar is left open. A schema that rejects the file it was generated from is worse than no schema.
• Namespaces line up — A target namespace is declared only when the document itself was written into one, because a schema declaring a namespace the instance does not use validates nothing.

Plenty of systems still speak XML and will not speak anything else. Converting lets you reuse data you already have in JSON without rewriting the producer, and it is usually the cheapest step in an integration.

• Enterprise and SOAP integration — SOAP services, EDI gateways and older ERP systems accept XML only. A converted payload is often the whole of the work.
• Configuration and build files — Ant, Maven, Spring, Android layouts and .NET config are all XML. Data generated as JSON has to arrive in that shape.
• Schema validation — XML has XSD, which lets a receiving system reject a malformed payload before it does anything with it. JSON Schema exists but far fewer systems enforce it.
• Documents rather than data — XML handles mixed content — text with markup inside it — which JSON has no way to express at all. That is why publishing formats are XML.
• Privacy — The conversion runs on your device. Nothing about the payload leaves it, which matters when the payload is customer records and the alternative is pasting them into someone's server.

A 9 MB JSON file converts to 17.8 MB of XML in about six-tenths of a second, without the page freezing.

• Root element — The single top-level tag. Must be a legal XML name; one that is not is repaired and the change is shown.
• Array item tag — The element name used for each item of an array when the naming mode is set to a fixed tag.
• Array item naming — Fixed tag, the parent key, or the singular of the parent key.
• Invalid key handling — Repair the key to a legal XML name, or keep the original text in a name attribute.
• Null values — An empty element, xsi:nil, or omitted from the document.
• Attribute mapping — Treat @keys as attributes and #text as element text.
• Type annotations — Add type="number", type="string" or type="boolean" to every element. Pro.
• Namespace and prefix — A target namespace URI for the document, bound as the default namespace or to a prefix. Pro.
• XML declaration — Whether to write the version and encoding line at the top.
• Output encoding — UTF-8, UTF-16 or ISO-8859-1 — declared and actually encoded.
• Indentation — Two spaces, four spaces, tabs, or one compact line.
• File name — The stem used for the downloaded .xml and .xsd.

Everything that decides whether the conversion is correct is free. The plan decides how much you can put through it at once and whether the extras come with it.

• Free — One file at a time, up to 10 MB — roughly forty thousand records of a typical export. Every structural setting, every naming mode, every null policy, attribute mapping, all four indents and all three encodings.
• Pro — No imposed size cap — up to what your device can handle. Up to 50 files converted in one press and downloaded as a single ZIP, plus XSD generation, target namespaces and type annotations.
• What a refused file gets — The actual size, the cap and a link to the JSON minifier, which is genuinely the right first move on a file that is a few megabytes over. Never a progress bar that then fails.

• XML to JSON
• JSON Formatter
• JSON to YAML
• JSON Tools
• Check it parses at all

  Confirms the document is valid JSON and says where it stops being valid if not

• Flatten it into a table

  When a person with a spreadsheet is the consumer rather than a system with a schema