Payload Formats for Constrained IoT

It's tempting to default to JSON for every payload an IoT device sends, because tooling for it is everywhere. On a Wi-Fi-connected device talking to a nearby gateway, that's usually fine. On a battery-powered sensor talking over a narrowband radio link, it can be the difference between a device that lasts a season and one that needs a battery swap every month.

What actually costs you

• Bytes on air. Every extra byte in a JSON payload — key names, braces, quotes — is airtime, and airtime is battery and channel time.
• Parsing cost on the receiving gateway. Usually negligible unless the gateway itself is resource-constrained.
• Developer time to debug. This is JSON's real advantage — it's human-readable without extra tooling.

A practical framework

| Format | Best for | Cost | |---|---|---| | JSON | Gateway-to-cloud, debugging-heavy stages | Verbose on the wire | | CBOR / MessagePack | Sensor-to-gateway over constrained radio | Needs a decoder on both ends | | Fixed-width binary struct | High-frequency, well-known payload shapes | Least flexible, smallest, fastest |

A pattern that works well in practice: use a compact binary format (fixed-width struct or CBOR) on the constrained sensor-to-gateway hop, then re-encode to JSON at the gateway before publishing upstream over MQTT. The gateway absorbs the complexity so the cloud-side integration stays simple and debuggable.

[Sensor] --(binary/CBOR, narrowband)--> [Gateway] --(JSON over MQTT, broadband)--> [Cloud]

When to skip the optimization

If the device already has reliable Wi-Fi or Ethernet and isn't battery-powered, none of this matters much — ship JSON and move on. Payload optimization is worth the added complexity specifically when the link is constrained (radio, LPWAN, cellular in poor-coverage areas) or the device is battery-powered and long field life matters.