What is the difference between XML and JSON?

A system has asked you for an XML file, and all you have is a .json export from some app. Or the other way round: your accountant sent you an invoice as XML and the program you want to load it into expects JSON. This article answers the one question you have at that moment: what exactly separates the two formats, and which part of that difference matters for your task.

The short answer: both carry data as plain text, and both can hold the same information. They differ in how the data is marked up and in which one the program on the other end knows how to read. In other words, most of the time you are not the one choosing; the receiving system chose long ago. Your job is to recognise what you have and to know what changes when you convert it.

One record, two formats: see the difference

The quickest way to grasp the difference is to put the same information side by side. In the diagram below, an order number, a customer and an amount are written by hand, first as XML and then as JSON. The content is identical; only the wrapping changes.

In XML every value sits inside a tag: it opens with <customer> and closes with </customer>. Because each name is written twice, the same record runs longer in XML. In JSON the name appears once, followed by a colon and the value, and curly braces mark where the record begins and ends. The character count under the diagram puts a number on that difference.

Which one is your file? Look at the first character

The extension does not always tell the truth. Some programs hand out XML named .txt or .dat, and some services download JSON with no extension at all. The reliable test is to look inside, and you need nothing special for it. Start Notepad (TextEdit on a Mac) and pick the file through the program's own File > Open command. On Windows, set the file type box at the bottom right of that window to "All files", or anything not ending in .txt stays hidden from the list. In the text that appears, skip any blank space and look at the first visible mark:

• If it is <, and especially if the file starts with <?xml, you are holding XML
• If it is { or [, it is JSON
• If the lines are plain text split by commas or semicolons, it is neither; most likely a CSV file
• If you see unreadable symbols, the file is not text at all (a compressed package, for example), so neither format applies

The differences in one table

Here is what the diagram means in practice. Pay particular attention to the third row: it is the difference that surprises people most during conversion, and it comes back in the sections below.

Why does one system want XML and another JSON?

The program that will read the file decides the format; it expects whatever it was built around. XML is the older of the two, and a great deal of official document exchange, accounting software and business-to-business plumbing was built on it. Many countries' electronic invoices are XML documents, which is why an e-invoice from a supplier or accountant so often arrives as a .xml file.

JSON, meanwhile, became the common language of web services and phone apps. When you press "download my data" in an app, or when two programs talk behind a website, what travels between them is usually JSON. RSS news feeds and the sitemaps that websites hand to search engines (sitemap.xml) are still XML.

The practical upshot: the question "which one is better?" rarely matters to you. If the other side expects XML, even flawless JSON will be turned away. When the format you have does not match the one requested, the task is conversion; if the choice really is yours, look at the sample file in the receiving program's help pages and stick with that format.

What changes when you convert, and is anything lost?

The two formats carry the same information but not in the same mould, so conversion is an adaptation rather than a copy. The converters on this site adapt your data as follows, and they do not hide it:

• XML to JSON: details attached to a tag are kept as a field whose name starts with @. The number in <order id="1042"> shows up in JSON as "@id": "1042"
• XML to JSON: every value arrives as quoted text. XML does not separate numbers from text in the file, so 249.90 becomes "249.90"; whatever program does the arithmetic has to turn it back into a number
• XML to JSON: the notes between <!-- --> and the <?xml ?> line at the top are not carried over, because JSON has nowhere to put them
• JSON to XML: no details are attached to tags; every key becomes a separate element, so if the receiving system expects the number inside the tag, you will need to edit the output by hand
• JSON to XML: the line between numbers and text disappears; both end up as plain text inside a tag

Do not convert an official document and send it back

Those adaptations have a consequence: convert a file from XML to JSON and back to XML, and you will not get the original document back character for character. Element names, order and the position of extra details can all shift. For everyday data this hardly matters; for an official document it does.

In digitally signed documents such as e-invoices, the signature is tied to every single character of the file; change one space and the signature no longer verifies. The legitimate reason to convert such an XML is to read it: to see the line items or move the amounts into another table. Keep the original untouched, send the original if it has to go anywhere, and keep the converted copy for your own use.

Before converting, make sure the file is sound

Converters only work on a document that follows its own rules. In XML, a single unclosed tag or an unquoted value makes the whole file unreadable. If your XML is squashed onto one line, or a system reports "invalid file", paste it into the XML Formatter first: the text gets indented, and if there is an error you are told its line and column. For JSON, the JSON Formatter does the same job.

This check has one limit worth knowing. It tests whether the document is correctly written, not whether it contains every field the receiving system needs. Which fields are mandatory is set by the schema file (XSD) that the organisation publishes. So "well-formed" means the file can be read; it does not promise that the organisation will accept it.

Frequently asked questions

Is XML or JSON better?

There is no overall winner. Whichever format the receiving system asks for is the right one. If the choice is entirely yours and the data will move between apps or web services, JSON is shorter and more common; for formal document exchange between organisations, XML is still the standard.

Do I lose information when I convert XML to JSON?

The values stay; their shape changes. Details attached to tags turn into fields starting with @, and numbers arrive as quoted text. The only thing that drops out is the notes between <!-- and -->, because JSON has no place for comments.

How can I read an XML invoice comfortably?

To see the line items as a table, the XML to Excel tool turns repeated records into rows and fields into columns. To simply look through the content, the XML Formatter indents the text so it becomes readable. Your original file is not touched either way.

Can I give my JSON file to a system that wants XML?

Yes, after converting it with the JSON to XML tool. Before sending, compare the result with the system's sample file: the outermost tag and the name used for list items should match what it expects. The tool lets you type the name of the outer tag yourself.

Are HTML and XML the same thing?

They look alike, since both use tags in angle brackets. But HTML has a fixed set of tags that describe how a page looks on screen; in XML, whoever prepares the data chooses the tag names, and the point is the data itself rather than its appearance.

Last updated: October 12, 2026