Sparkplug B vs JSON over MQTT: Which Payload Should You Use?

Sparkplug B vs JSON is one of the first design decisions in any industrial MQTT project, and the answer is rarely "one or the other forever". In this comparison you will learn how the two approaches differ in interoperability, state awareness, bandwidth and tooling, when each one fits, and how to combine them so machines speak Sparkplug while people and dashboards read JSON.

Two Different Philosophies

MQTT itself does not care what is inside a message. That is both its strength and the reason this debate exists.

Plain JSON over MQTT means you design your own topics and payloads. A temperature sensor might publish {"temp": 21.4, "unit": "C", "ts": 1792137600} to plant1/hall2/sensor7/telemetry. Anyone can read it, every language parses it, and you can start in five minutes.

Sparkplug B is a specification on top of MQTT. It fixes the topic structure (spBv1.0/group/type/node/device), encodes payloads in Protobuf, and adds a state model with birth and death certificates, sequence numbers and commands. You give up freedom and get interoperability with any Sparkplug-aware SCADA or host application.

Here is the same reading as JSON:

{
  "timestamp": 1792137600123,
  "spindleSpeed": 1462.3,
  "spindleRunning": true
}

As Sparkplug B, the equivalent DDATA payload is binary Protobuf. After decoding it looks like this, but on the wire it is compact bytes with aliases instead of names:

{
  "timestamp": 1792137600123,
  "seq": 17,
  "metrics": [
    { "alias": 3, "datatype": 10, "doubleValue": 1462.3 },
    { "alias": 4, "datatype": 11, "booleanValue": true }
  ]
}

Sparkplug B vs JSON Side by Side

Where Sparkplug B Wins

Interoperability

The biggest argument for Sparkplug is that a gateway from one vendor and a SCADA system from another can work together without a mapping project. The host reads births, discovers every metric with its datatype and starts displaying data. With JSON, every new data source needs someone to agree on field names, units and timestamps.

State awareness

Sparkplug tells you not only the last value but whether it is still valid. When a gateway loses power, the broker publishes its NDEATH, and every host marks the related tags stale. With JSON you can approximate this with a last will on a status topic, but you also need retained values, a convention for device-level status and logic in every consumer.

Bandwidth

Protobuf with metric aliases is considerably smaller than JSON that repeats field names in every message. Combined with report by exception, where only changed values are sent, Sparkplug suits cellular and satellite links well. For a handful of sensors on plant Ethernet the difference rarely matters.

Where JSON Wins

Simplicity and readability

You can debug JSON with mosquitto_sub and your eyes. Web developers, data engineers and IT teams already know it. Low-code tools such as Node-RED handle it natively.

Flexibility

JSON lets you model topics around your plant hierarchy, for example an ISA-95 tree, which is how many teams structure a Unified Namespace. Sparkplug's fixed namespace stops at group, node and device.

Non-industrial consumers

Mobile apps, web dashboards, cloud functions and analytics notebooks usually want JSON. Feeding them Sparkplug means each one needs the proto file and alias handling.

Try Both on a Test Broker

You can compare readability yourself on the public MQTT test broker. Publish JSON:

mosquitto_pub -h broker.connectmq.com -p 1883 -i json-test-a81c \
  -t "connectmq/demo/a81c/line1/cnc1/telemetry" \
  -m '{"timestamp": 1792137600123, "spindleSpeed": 1462.3, "spindleRunning": true}'

Then run a Sparkplug simulator, such as the one in our guide to Sparkplug birth and death certificates, and subscribe to both with verbose output. The JSON prints cleanly; the Sparkplug messages print as partly binary text until you decode them. The public area is readable by everyone, so use random IDs and no real data.

The Hybrid Pattern: Sparkplug at the Edge, JSON for Consumers

Many plants end up with both. Edge nodes and SCADA speak Sparkplug B for reliable, state-aware transport, and a translation layer publishes readable JSON into an ISA-95 topic tree for dashboards, analytics and IT systems.

You can build that translation layer yourself: a Python service that subscribes to spBv1.0/#, decodes Protobuf, resolves aliases and republishes JSON. Our tutorial on how to decode Sparkplug B in Python is a solid starting point.

Alternatively, let the broker do it. ConnectMQ decodes Sparkplug B and can republish it into ISA-95 topics, so spBv1.0/factory1/DDATA/line1/cnc1 appears as connectmq/factory1/production/line1/cnc1/telemetry. Dashboards, Node-RED flows and Telegraf agents subscribe to the readable topics as ordinary MQTT clients, while your Sparkplug hosts keep using the original namespace. The portal also shows the decoded Sparkplug view in its topic explorer, so engineers see metric names instead of bytes.

Decision Checklist

1. Do you have, or plan to buy, a Sparkplug-aware SCADA or host application? If yes, lean Sparkplug.
2. Do operators need to know when values are stale? Sparkplug gives you this without custom code.
3. Are links metered or low bandwidth? Sparkplug with aliases and report by exception helps.
4. Is the team mostly web and IT developers with a few sensors? JSON gets you moving faster.
5. Do you want topics organised by ISA-95 levels? JSON fits naturally, or use the hybrid pattern.
6. Will many non-industrial apps consume the data? Provide JSON, either natively or by translation.
7. Are you mixing vendors at the edge? Sparkplug reduces mapping work.

If you answered yes to items from both sides, the hybrid approach is usually the right one.

The Broker Is the Same Either Way

Both payloads run on any standards-compliant MQTT broker, so this decision does not lock you into infrastructure. What changes is how much visibility you get. A hosted MQTT broker that understands Sparkplug and ISA-95 topics makes the binary side as approachable as the JSON side. For the broader architecture, read MQTT, Sparkplug B and the Unified Namespace and the Industrial IoT with MQTT guide.

Get Started with ConnectMQ

Create a free Serverless broker at app.connectmq.com, no credit card required. Publish JSON and Sparkplug B side by side, and see both readable in the ConnectMQ topic explorer, with Sparkplug data republished into ISA-95 topics.

Frequently Asked Questions

Is Sparkplug B always better than JSON for industrial IoT?

No. Sparkplug B is better for interoperability with SCADA and for built-in state awareness. JSON is simpler and more flexible, and it is often the better choice for small projects or IT-facing consumers.

Can Sparkplug use JSON instead of Protobuf?

The Sparkplug B specification defines Protobuf encoding. Some tools offer a JSON representation for debugging or bridging, and ConnectMQ can decode both forms.

Can I mix Sparkplug B and JSON on the same broker?

Yes. They use different topics, so they coexist without conflict. Many plants run Sparkplug under spBv1.0 and JSON under an ISA-95 tree on the same broker.

Does JSON over MQTT support device online status?

Not by itself. You can implement it with a retained last will message on a status topic, but you have to define and enforce the convention yourself.