Few standards are as ubiquitous as JSON and XML. The two data formats are widely used throughout the web to work with data, and for a good reason — they represent some of the most efficient and useful data representation methodologies available to developers.

So, how are JSON and XML different? Below, we look at JSON and XML and compare their strengths and weaknesses. For a similar comparison between JSON and YAML, you can read our other piece here.

What Is JSON?

JSON, properly known as JavaScript Object Notation, is a powerful open standard for data interchange and file formatting. The technology utilizes attribute-value pairs and arrays to create a human-readable format that is widely used for data interchange. It was first created to fill the need for stateless, real-time server-to-browser communication, with a particular focus on security and minimal file size. In 1999, JSON was published as a subset of JavaScript under the Standard ECMA-262 3rd Edition; later developments saw it standardized under both RFC 8259 and Internet Standard STD 90. JSON is additionally currently codified under ISO/IEC 21778:2017.

In its most basic form, JSON is an attribute-value pair. An attribute represents a statement about the nature of a thing, and then the value states a quality about that same thing. The syntax thus allows for the establishment of an entity and a value. For example,companyName and NordicAPIs. The syntax for this pair is as follows:

{
  "companyName": "NordicAPIs",
}

JSON supports various data types for these attribute-value pairs, allowing for a range of potential definitions. Numbers, Strings, Booleans, Arrays, and Objects are all supported data types, allowing a single JSON file to define most entities in an easy to parse, easy-to-understand methodology. Since the data typing in JSON is so simple, it’s often used at scale to facilitate high-information, low-overhead data interchange. With JSON, you tend to get more complex definitions for a lower total overhead than other solutions.

JSON structures can handle quite a lot of complexity. In this example response from the National Weather Service, the JSON provides a list of weather events for the region of Texas with multiple different data types.

{
    "@context": [
        "https://geojson.org/geojson-ld/geojson-context.jsonld",
        {
            "@version": "1.1",
            "wx": "https://api.weather.gov/ontology#",
            "@vocab": "https://api.weather.gov/ontology#"
        }
    ],
    "type": "FeatureCollection",
    "features": [
        {
            "id": "https://api.weather.gov/alerts/urn:oid:2.49.0.1.840.0.8556b5f144b57c3b8b9f5f08f36431bbd4de1b3e.001.1",
            "type": "Feature",
            "geometry": null,
            "properties": {
                "@id": "https://api.weather.gov/alerts/urn:oid:2.49.0.1.840.0.8556b5f144b57c3b8b9f5f08f36431bbd4de1b3e.001.1",
                "@type": "wx:Alert",
                "id": "urn:oid:2.49.0.1.840.0.8556b5f144b57c3b8b9f5f08f36431bbd4de1b3e.001.1",
                "areaDesc": "Coastal Willacy; Coastal Cameron; Coastal Kenedy",
                "geocode": {
                    "SAME": [
                        "048489",
                        "048061",
                        "048261"
                    ],
                    "UGC": [
                        "TXZ256",
                        "TXZ257",
                        "TXZ351"
                    ]
                },
                "affectedZones": [
                    "https://api.weather.gov/zones/forecast/TXZ256",
                    "https://api.weather.gov/zones/forecast/TXZ257",
                    "https://api.weather.gov/zones/forecast/TXZ351"
                ],
                "references": [
                    {
                        "@id": "https://api.weather.gov/alerts/urn:oid:2.49.0.1.840.0.0bc7e358229e3139787c9fe41b0229e8b96a628e.001.1",
                        "identifier": "urn:oid:2.49.0.1.840.0.0bc7e358229e3139787c9fe41b0229e8b96a628e.001.1",
                        "sender": "w-nws.webmaster@noaa.gov",
                        "sent": "2021-11-08T03:52:00-06:00"
                    }
                ],
                "sent": "2021-11-08T11:34:00-06:00",
                "effective": "2021-11-08T11:34:00-06:00",
                "onset": "2021-11-08T18:00:00-06:00",
                "expires": "2021-11-09T00:00:00-06:00",
                "ends": "2021-11-09T00:00:00-06:00",
                "status": "Actual",
                "messageType": "Update",
                "category": "Met",
                "severity": "Minor",
                "certainty": "Likely",
                "urgency": "Expected",
                "event": "Coastal Flood Statement",
                "sender": "w-nws.webmaster@noaa.gov",
                "senderName": "NWS Brownsville TX",
                "headline": "Coastal Flood Statement issued November 8 at 11:34AM CST until November 9 at 12:00AM CST by NWS Brownsville TX",
                "description": "* WHAT...Isolated minor coastal flooding expected.\n\n* WHERE...Coastal Kenedy, Coastal Cameron and Coastal Willacy\nCounties.\n\n* WHEN...This evening.\n\n* IMPACTS...Wave run-up may approach the dunes along narrow\nbeaches. Beach equipment, such as umbrellas and chairs, could\nbe moved by waves. Vehicles driving along narrow beaches may\nexperience higher water levels. Elevated water levels may also\noccur across the Laguna Madre and South Bay, and along State\nHighway 4 west of Boca Chica State Park.\n\n* ADDITIONAL DETAILS...High tide occurs at 9:49 PM CST.",
                "instruction": "Do not drive through flooded roadways.",
                "response": "Monitor",
                "parameters": {
                    "PIL": [
                        "BROCFWBRO"
                    ],
                    "NWSheadline": [
                        "COASTAL FLOOD STATEMENT REMAINS IN EFFECT FROM 6 PM CST THIS EVENING THROUGH MIDNIGHT CST TONIGHT"
                    ],
                    "BLOCKCHANNEL": [
                        "EAS",
                        "NWEM",
                        "CMAS"
                    ],
                    "VTEC": [
                        "/O.CON.KBRO.CF.S.0027.211109T0000Z-211109T0600Z/"
                    ],
                    "eventEndingTime": [
                        "2021-11-09T06:00:00+00:00"
                    ]
                }
            }
        }
    ],
    "title": "current watches, warnings, and advisories for Texas",
    "updated": "2021-11-08T17:35:27+00:00"
}

Pros and Cons of JSON

The biggest benefit of adopting JSON is its relative efficiency. Compared to other solutions, JSON delivers highly efficient data interchange. JSON is very lightweight due to its simplistic value-attribute system, and as such, it’s most effective in limited throughput situations such as transit across Internet of Things devices. This simplicity generally means quicker parsing and generation, resulting in a quick turnaround for requests.

Another big benefit is that JSON is highly readable for the human user. Not all data is meant for machine consumption, and many lightweight or highly compressed solutions can often be useful for machines but unreadable for the end-user. JSON is easy to read and understand, and what you see is typically what you get.

Of course, that simplicity can, in some cases, be a significant drawback. JSON doesn’t provide many options for tagging or adding metadata, which can significantly limit your dataset. While some technical implementations can provide additional data for JSON-returned objects, an API would have to use two separate solutions to do what other single-implementation solutions support by default.

This lack of metadata and tagging also means that data combination is more difficult. JSON is what JSON is, and when importing two datasets that have a shared entity attribute — for instance, two systems where CityID means vastly different things — naming collisions can result in data conflicts.

What Is XML?

XML, or Extensible Markup Language, is a standard markup language and file format for data interchange. XML utilizes hierarchical markup to store and exchange data, utilizing opening and closing tags to delineate data content entities from other entities in the same document.

XML started as a solution to a core problem with HTML. Because HTML, or Hypertext Markup Language, doesn’t allow for extensible element creation, XML was developed to provide this extensibility. XML was built upon earlier extensible language solutions, with IBM’s GML (Generalized Markup Language) and its descendent standard SGML (Standard Generalized Markup Language) forming its core historical origins.

The standard utilizes DTDs, Document Type Definitions, to define document types and assign meaning to the tags used within the XML file. Notably, XML provides a standard set of tags and allows for creator-defined tagging, meaning that XML files paired with proper XML DTD parsing rules can represent everything from websites to graphics.

XML is notably verbose — first, let’s review the JSON attribute demonstrated earlier in this piece.

{
  "companyName": "NordicAPIs",
}

In XML, the format becomes much more verbose.

<xml>
    <companyData>
        <companyName>NordicAPIs</companyName>
    </companyData>
</xml>

As with JSON, XML is highly human-readable, but since it is also paired with instructions for how to parse the contents of each file, it’s also highly machine-readable.

Pros and Cons of XML

XML is verbose, and in many cases, that is a strong positive. Whereas JSON doesn’t provide a great deal in the way of tagging and metadata, XML offers a great deal of information for every data point. More than that, the DTD and schema inherent in XML mean that more complex data structures can be created on the fly using custom data typing that is not supported with JSON.

A significant benefit of XML over JSON is separating the message format and processing that format. JSON is defined and processed as a singular entity, but since XML DTD can define its own processing, the message format and processing are ultimately decoupled. This means that the integrity of the data is assured regardless of the nature of the XML file and the system that processes it.

Unfortunately, XML’s complexity in its metadata and tagging support can itself be viewed as a negative. XML can be so dense with complex data sets that it becomes unmanageable. Let’s look at a sample JSON file that states a company name, address, phone number, and contact.

{
  "companyName": "NordicAPIs", "companyAddress": "1 API Street", "companyPhone": "555-555-5555", "companyContact": "Nordic Writer",
}

With XML, the output is longer.

<xml>
    <companyData>
        <companyName>NordicAPIs</companyName>
        <companyAddress>1 API Street</companyAddress>
        <companyPhone>555-555-5555</companyPhone>
        <companyContact>Nordic Writer</companyContact>
    </companyData>
</xml>

While this is only a slight difference with this amount of data, it adds up very quickly. Over time, a file with only a medium amount of data can balloon out of control compared to other, more streamlined systems.

Choosing the Right Toolset

Ultimately, JSON and XML are designed to do the same thing in different ways.

JSON is a standard interchange format that prioritizes efficiency above all else — it’s lightweight and easy to parse. If this means that it loses some of its ability to provide a more complex data representation, so be it. JSON is designed to be easy for developers to read. As such, machine readability is less prioritized — the hierarchy of data is almost absent from most JSON documents.

On the other hand, XML is a standard interchange format that prioritizes completeness above all else. It ultimately shines brightest when providing complexity and hierarchical organization that represents the data structure in its entirety. Unfortunately, this also means that XML is often larger and less efficient comparatively.

The answer, then, is in what the developer prioritizes — lightweight interchange for simple data structures prefer JSON, while more complex structures that require the hierarchical representation of XML.