JSON and XML in API: 5 Key Differences Explained

 JSON and XML in API testing

Almost every API you test sends and receives data as JSON or XML. JSON dominates REST APIs; XML is still everywhere in SOAP services, banking, insurance and enterprise integrations. This guide shows the same data in both formats, how their data types and schemas work, how to query and validate each in Postman and REST Assured, and the pitfalls that cause real bugs.

The Same Data in Both Formats

JSON

{
  "id": 101,
  "name": "Asha",
  "email": "asha@example.com",
  "active": true,
  "roles": ["admin", "tester"],
  "address": { "city": "Pune", "zip": "411001" },
  "manager": null
}

XML

<user>
  <id>101</id>
  <name>Asha</name>
  <email>asha@example.com</email>
  <active>true</active>
  <roles>
    <role>admin</role>
    <role>tester</role>
  </roles>
  <address>
    <city>Pune</city>
    <zip>411001</zip>
  </address>
  <manager/>
</user>

JSON uses objects {}, arrays [] and key–value pairs; XML uses nested opening and closing tags, plus optional attributes, such as <user id="101">. The XML version is longer, and it has no built-in way to say "this is a number" or "this is a list" — that comes from a schema.

JSON vs XML at a Glance

More on the API styles behind them: REST vs SOAP.

Why JSON Is the Default for REST APIs

• Lightweight — less data over the network than equivalent XML.
• Native data types — numbers, booleans, null and arrays without a schema.
• Easy to parse — built into JavaScript and every major language.
• Readable — simple for developers and testers to scan.

Interview tip:

"A JSON response is the data an API returns in JSON format. REST APIs prefer JSON because it's lightweight, has native data types and is easy to parse; XML is still common in SOAP and enterprise systems, where schemas, namespaces and strict contracts matter."

Querying the Response: JSONPath vs XPath

Validating in Postman

JSON

pm.test("Content-Type is JSON", () =>
    pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json"));

const body = pm.response.json();

pm.test("Fields and types", () => {
    pm.expect(body.id).to.be.a("number");
    pm.expect(body.roles).to.include("tester");
    pm.expect(body.address.city).to.eql("Pune");
});

XML

Convert the XML response to a JavaScript object first:

const xml = xml2Json(pm.response.text());

pm.test("XML name", () =>
    pm.expect(xml.user.name).to.eql("Asha"));

More: Postman Cheat Sheet.

Validating in REST Assured

JSON — GPath Paths

when().get("/users/101").then()
    .contentType(ContentType.JSON)
    .body("id", equalTo(101))
    .body("roles", hasItem("tester"))
    .body("address.city", equalTo("Pune"));

XML — XmlPath and XPath

when().get("/users/101.xml").then()
    .contentType(ContentType.XML)
    .body("user.name", equalTo("Asha"))
    .body(hasXPath("//address/city", equalTo("Pune")));

More: REST Assured Response Validation.

JSON vs JSON Schema

JSON carries data. JSON Schema is itself written in JSON and describes the rules that data must follow — required fields, types, formats, allowed values, array sizes and whether extra fields are allowed.

Validating against a schema is a contract test: it catches a renamed field or a number that suddenly arrives as a string.

{
  "type": "object",
  "required": ["id", "name", "email", "roles"],
  "properties": {
    "id": {
      "type": "integer"
    },
    "name": {
      "type": "string",
      "minLength": 1
    },
    "email": {
      "type": "string",
      "format": "email"
    },
    "active": {
      "type": "boolean"
    },
    "roles": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "minItems": 1
    },
    "address": {
      "type": "object",
      "required": ["city"],
      "properties": {
        "city": {
          "type": "string"
        },
        "zip": {
          "type": "string"
        }
      }
    },
    "manager": {
      "type": ["string", "null"]
    }
  },
  "additionalProperties": false
}

Run against the sample JSON above, this schema passes. Change "id": 101 to "id": "101" and it fails with '101' is not of type 'integer' — exactly the kind of silent contract break schema tests exist for.

For XML, the equivalent is an XSD.

More: JSON Schema Validation in REST Assured.

Pitfalls That Cause Real Bugs

• Number vs string — 101 and "101" look the same on screen but can break typed clients.
• null vs missing vs empty — "manager": null, no manager key, and "manager": "" mean different things; check the API contract.
• Dates and time zones — agree on a format such as ISO 8601, for example 2026-09-25T10:00:00Z, and test time-zone edges.
• Precision — money represented as floating-point numbers can lose precision; many APIs send it as a string or in minor units.
• Special characters — quotes, backslashes and Unicode need appropriate handling in JSON; & and < must be escaped in XML.
• Wrong Content-Type — sending JSON without Content-Type: application/json often returns a 415 response.
• XML namespaces — XPath queries can fail if you ignore the namespace; use local-name() or register the namespace.

Practise designing checks like these for real endpoints in the API Testing Scenario Lab.

From Real Projects

My API testing experience covers CRUD operations, HTTP methods, JSON path, and validating JSON and XML data. On Testsigma, a platform that itself automates API tests, understanding requests, responses and status codes was part of understanding the product. Whatever tool you use, validate the status code, the response structure and the values — not just that the call returned something. Validate the structure of the response as well as the values — a missing field is a defect too.

📚 Official documentation: MDN: HTTP · ISTQB Glossary of testing terms

FAQs

Why is JSON used in APIs?

It's lightweight, readable, has native data types and is easy to parse in every language — which is why most REST APIs use it.

What is the difference between JSON and XML?

JSON uses objects and arrays with native types; XML uses nested tags where everything is text unless a schema defines types. JSON is more compact; XML supports namespaces, attributes and comments.

How do you test a JSON response?

Check the status and Content-Type, required fields, values and data types, arrays, and validate the whole structure against a JSON Schema — in Postman or REST Assured.

What is the difference between JSON and JSON Schema?

JSON carries data; JSON Schema defines the rules that data must follow, and is used to validate requests and responses.

How do you validate XML responses?

Query values with XPath or XmlPath, and validate the structure against an XSD. In Postman, convert XML with xml2Json() before asserting.

Where is XML still used?

SOAP web services, banking, insurance, telecom and government integrations, and many configuration files.

Related

• API Testing Fundamentals
• HTTP Requests & Responses
• The Complete API Testing Tutorial
• Top 30 API Testing Interview Questions