JSON vs XML
JSON and XML are both in wide use and are chosen for different reasons. This page sets them against each other on the things that decide between them, and links to the converters for both directions — every one of which runs in your browser, with the file never uploaded.
The short answer
Both hold nested data and both are text, so either can express almost anything the other can. JSON does it with far less ceremony: no closing tags, no attributes-versus-elements decision, and a shape that maps directly onto the data structures of every modern language. That is why it displaced XML for APIs almost completely.
XML retains the advantages of its age and its ambition. It has real schema languages, namespaces for mixing vocabularies, and a query language in XPath, and it handles documents — prose with markup through it — in a way JSON cannot express at all. Publishing, government data, and office file formats still run on it for those reasons.
If you are converting XML to JSON, the thing to check is attributes. Every converter has to invent a convention for them, and the two most common — prefixing the key or nesting them under a separate object — produce different JSON from the same XML. Whichever one your tool uses, the result no longer converts back to the file you started with.
Side by side
| Property | JSON | XML |
|---|---|---|
| Stored as | Plain text, readable in any editor | Plain text, readable in any editor |
| What it can hold | Values nested inside values | Values nested inside values |
| Numbers stay numbers | Yes | No |
| Comments | No | Yes |
| Several in one file | No | No |
| Published | 2001 | 1998 |
Where they actually differ
- Only JSON knows what kind of value it is holding. In the other everything is text, which is why leading zeros vanish and long numbers turn into scientific notation.
- Only XML has a syntax for comments. Converting away from it loses every explanation in the file while keeping all of the data.
- They are near contemporaries, which is why they overlap as much as they do.
What people get wrong
- Converting into the untyped format turns every value into text. Leading zeros disappear, long numbers become scientific notation, and dates come back in whatever form the reading program guesses.
- Comments do not survive into a format with no syntax for them. The data arrives intact and every explanation of it is gone, which makes that direction effectively one-way.
Which to choose
- Choose JSON when
- Choose JSON for APIs, configuration, and data moving between programs, where less ceremony and direct mapping to native types win.
- Choose XML when
- Choose XML for documents, for anything needing schema validation or namespaces, and where an existing system already speaks it.
Converting between them
Common questions
- Does XML convert to JSON cleanly?
- Not always. XML distinguishes attributes from child elements and allows text and elements to be mixed in the same node, and JSON has no equivalent of either. Converters adopt conventions — prefixing attribute names, for instance — and the result is valid JSON that no longer round-trips back to the original XML.
- Which of JSON and XML is better?
- Neither, in general — if one were simply better the other would have disappeared. They are good at different things, and the short answer above says which is which. The useful question is what the file has to do next: be edited, be published, be opened by somebody else, or fit inside a size limit.
- Does converting between them lose anything?
- It depends on the direction. Converting into a format that stores everything loses nothing but does not recover anything either; converting into one that discards detail loses a little each time. The table above says which of these two does which.
- Can I convert back afterwards?
- The file will convert back, but whether it comes back unchanged depends on the direction. Between two formats that store everything, a round trip is lossless. Where one of them discards detail, that detail is gone and the return journey cannot invent it.
- Can I use both?
- On a web page, often yes, and it is usually the right answer: serve the smaller modern format and list an older one as a fallback so each browser takes what it understands. For a file you are handing to a person, pick one — the one they can open.
- Which one does my software support?
- The side-by-side table above says which browsers read each, which is the part that varies most. Desktop support is harder to state in general and tends to lag browsers by years, so if the file is going to somebody else, the older and more widely read of the two is the safer choice.
- Is converting between them free?
- Yes, with no account and no limit on how many files you convert. Every converter linked from this page runs in your browser: the file is read from your device, converted by code running on it, and handed back as a download.
- Is my file uploaded?
- No. There is no conversion server here to upload it to, and no third-party service is involved. You can confirm it yourself: open your browser's developer tools, switch to the Network panel with no filter, and run a conversion — no request carries your file.