Data formats: JSON and XML

A protocol moves bytes. A data format, also called a data protocol, decides what those bytes say, so that the machine at the other end can take them apart again and find the temperature.

Two formats are in common use: JSON and XML. If you are new to IoT and have never had to read either, this page is the one to read carefully, because almost every payload, API response and configuration file you meet from here on will be one of them.

JSON

JSON, JavaScript Object Notation, is a lightweight text format for structured data. It is text, so you can read it, and it is strict, so a machine can parse it without ambiguity. It is the usual choice for modern IoT work.

Here is a complete IoT payload:

{
  "deviceId": "sensor-042",
  "timestamp": "2026-08-14T09:15:00Z",
  "temperature": 25.5,
  "humidity": 41,
  "batteryOk": true,
  "errorMessage": null,
  "location": {
    "building": "Central Library",
    "floor": 2
  },
  "recentReadings": [25.1, 25.3, 25.5]
}

Everything in JSON is built from two containers and four simple values.

The two containers

An object is an unordered collection of name and value pairs, wrapped in curly braces. The name is always a string in double quotes, followed by a colon, then the value. Pairs are separated by commas.

{"temperature": 25.5, "humidity": 41}

An array is an ordered list of values, wrapped in square brackets and separated by commas. The values do not have to be the same type, though in practice they usually are.

[25.1, 25.3, 25.5]

The data types

Type	Written as	Example	Notes
String	Double quotes	"Central Library"	Always double quotes, never single
Number	Bare digits	25.5, 41, -3, 1.2e6	No quotes, no units, no distinction between whole and decimal
Boolean	true or false	true	Lowercase, no quotes
Null	null	null	Means "no value", which is not the same as 0 or ""
Object	{ }	{"floor": 2}	Can contain any of these, including more objects
Array	[ ]	[1, 2, 3]	Can contain any of these, including more arrays

That is the entire type system. There is deliberately nothing else, and the consequences of that are worth understanding.

Nesting

Objects and arrays contain each other, which is how JSON expresses structure of any depth. In the payload above, location is an object inside the main object, so floor sits one level down. You refer to a value by its path from the top:

temperature          → 25.5
location.building    → "Central Library"
recentReadings[0]    → 25.1

That dotted path notation is how most tools, including translators and rule conditions, address a field. Counting from zero in arrays is a common source of off-by-one errors.

An array of objects is the usual way to send several readings at once:

{
  "deviceId": "sensor-042",
  "readings": [
    {"time": "2026-08-14T09:00:00Z", "temperature": 25.1},
    {"time": "2026-08-14T09:05:00Z", "temperature": 25.3},
    {"time": "2026-08-14T09:10:00Z", "temperature": 25.5}
  ]
}

The rules that trip people up

JSON is strict, and its error messages are often unhelpful. The common mistakes:

• Keys must be in double quotes. {temperature: 25.5} is not JSON, even though it looks like it ought to be.
• Single quotes are never valid. {'a': 1} is not JSON.
• No trailing comma. {"a": 1, "b": 2,} is invalid, and this is the single most common error.
• No comments. There is no way to annotate JSON, which is why configuration files that need comments often use something else.
• true, false and null are lowercase and unquoted. "true" is a string, and a rule testing for a boolean will not match it.
• Numbers carry no units and no precision guarantee. 25.5 might be Celsius, Fahrenheit or something else entirely; only the field name or a data model tells you.
• There is no date type. Timestamps are strings, and should use ISO 8601 in UTC, as "2026-08-14T09:15:00Z", which sorts correctly as text and removes any question about time zone.
• Special characters inside strings are escaped with a backslash: \" for a quote, \\ for a backslash, \n for a newline.

Why it suits IoT

JSON is compact enough for constrained links, needs no schema to be readable, and every language and tool parses it natively. A person can open a payload and understand it, which matters more during commissioning than any theoretical elegance.

Its limits are the flip side of the same simplicity. Nothing in JSON says what a field means, what unit it is in, or which fields are required. That is exactly the gap that data models fill.

XML

XML, eXtensible Markup Language, is the older of the two and describes data using nested tags. It is more verbose than JSON, and correspondingly more explicit.

The same payload in XML:

<?xml version="1.0" encoding="UTF-8"?>
<measurement deviceId="sensor-042">
  <timestamp>2026-08-14T09:15:00Z</timestamp>
  <temperature unit="C">25.5</temperature>
  <humidity unit="%">41</humidity>
  <batteryOk>true</batteryOk>
  <location>
    <building>Central Library</building>
    <floor>2</floor>
  </location>
  <recentReadings>
    <reading>25.1</reading>
    <reading>25.3</reading>
    <reading>25.5</reading>
  </recentReadings>
</measurement>

The pieces

• The declaration, the first line, states the XML version and the character encoding.
• An element is an opening tag, content, and a matching closing tag: <floor>2</floor>. Every element must be closed, and an empty one may close itself as <floor/>.
• Elements nest, and there must be exactly one root element containing all the others. Here it is measurement.
• An attribute is a name and value on the opening tag: unit="C". Attribute values are always quoted.
• Comments are written <!-- like this -->, which XML permits and JSON does not.

Elements or attributes

XML lets the same information be expressed either way, which is its most frequent design argument:

<temperature unit="C">25.5</temperature>
<temperature><value>25.5</value><unit>C</unit></temperature>

The convention most people settle on is that attributes carry metadata about the element, such as a unit or an identifier, while elements carry the data itself. Attributes cannot nest or repeat, which decides the matter whenever the value has structure of its own.

Namespaces and schemas

Two features explain why XML persists in large systems.

A namespace lets documents from different vocabularies combine without their names colliding, by binding a prefix to a URI:

<rec:Building xmlns:rec="https://w3id.org/rec/">
  <rec:name>Central Library</rec:name>
</rec:Building>

A schema, usually XSD, is a separate document that formally defines which elements may appear, in what order, how many times, and of what type. A parser can then validate a document against it and reject anything that does not conform, before any application code runs. That guarantee is why XML remains common where correctness is contractual.

Where you meet it in IoT

XML appears in enterprise integrations, in SOAP web services, in a number of building and industrial systems, and in configuration and exchange formats such as those in the Open BIM family. Any platform integrating with an existing estate needs to read it.

The two side by side

	JSON	XML
Structure	Objects and arrays	Nested elements
Metadata	Fields in the object	Attributes or child elements
Comments	Not supported	Supported
Schema validation	Optional, via JSON Schema	Mature and widely used, via XSD
Namespaces	Not built in	Built in
Size on the wire	More compact	More verbose
Typical use in IoT	Device payloads, REST APIs, MQTT	Enterprise, building and industrial integrations

Both express the same information. JSON is the usual choice for new IoT work, and XML is what a great deal of existing infrastructure already speaks, so a horizontal platform handles both and converts between them where needed.

What neither of them tells you

Look again at the JSON payload at the top of this page. It says "temperature": 25.5. It does not say what unit that is, what precision to expect, whether the field is required, which physical thing was measured, or what room it belongs to.

Formats carry structure. Meaning comes from the layer above, which is where data models come in.