CoAP vs MQTT vs HTTP for IoT

The three protocols at a glance

The decision framework

Five questions determine which protocol fits:

1. How often does the device communicate? Constantly (seconds): MQTT. Occasionally (hours): HTTP. In between: depends on other factors.
2. Does the device need to receive commands from the cloud? Yes: MQTT or CoAP observe. No: any.
3. How constrained is the device? Under 32 KB RAM, battery-only: CoAP. Otherwise: MQTT or HTTP.
4. What network does it use? Mesh-IPv6 / 6LoWPAN: CoAP. Cellular / WiFi: MQTT or HTTP. Behind restrictive firewall: HTTP (port 443 always open).
5. What does the backend prefer? Existing REST API: HTTP. Stream processing platform: MQTT. Event-driven serverless: any.

MQTT: the default for connected IoT

MQTT is purpose-built for the IoT case where a device maintains a persistent connection and exchanges many small messages. Strengths:

• One TCP+TLS handshake per device lifecycle. The handshake cost (5-10 round trips) is paid once at boot, then thousands of messages flow with no further setup.
• Server push. Commands from cloud to device arrive immediately via the broker. No polling required.
• Tiny per-message overhead. 2-5 bytes plus payload.
• Pub/sub fanout. The broker handles many subscribers per device topic without device involvement.
• QoS for unreliable networks. Messages survive intermittent connectivity.
• Last Will + retain for state management. Built-in patterns for presence and state.

Best fit: a device that wakes up, connects, then publishes sensor data every few seconds for hours while staying responsive to commands.

Weakness: maintaining the TCP connection consumes battery on cellular IoT. Sleeping the radio between messages while keeping MQTT state is awkward. Devices using LTE-M with PSM (Power Save Mode) or NB-IoT often use HTTP or CoAP instead for this reason.

CoAP: the constrained-device specialist

CoAP (RFC 7252) was designed by the IETF for devices with as little as 10 KB of RAM running on networks like 6LoWPAN and Thread. It deliberately mirrors HTTP — GET, PUT, POST, DELETE methods; URI paths; content-type negotiation — but over UDP with a compact 4-byte header. Strengths:

• UDP. No connection state. The device can send a packet, get a response, and sleep — no TCP teardown overhead.
• 4-byte header. Smallest of the three protocols.
• Native multicast. A CoAP server can answer requests to a multicast group — useful for discovery in mesh networks.
• RESTful semantics. Easier for HTTP developers to learn than MQTT's broker model.
• Observe (RFC 7641). Long-lived subscriptions: client GETs a resource with an Observe option; server pushes updates whenever the resource changes. Comparable to MQTT subscribe but per-resource.
• Block-wise transfer (RFC 7959). Large payloads broken into UDP-sized chunks transferred reliably.

Best fit: very constrained devices on managed networks. Building automation, mesh sensor networks, smart agriculture sensors.

Weakness: UDP is unfriendly to NAT and corporate firewalls. CoAP works great in private networks but is awkward over the public internet without infrastructure like CoAP-over-TCP (RFC 8323) or a gateway that translates to HTTP/MQTT.

HTTP: the universal lowest-common-denominator

HTTP is the default for everything else. Strengths:

• Works everywhere. Every firewall allows outbound TCP 443. Every backend platform speaks HTTP.
• RESTful semantics. Familiar to all developers.
• Rich tooling. Endless libraries, debugging tools, observability platforms.
• Statelessness. Each request is independent; the server doesn't track which devices are "connected."
• Native to web technologies. Mobile apps, browser dashboards, and serverless functions all consume HTTP natively.

Best fit: devices that wake up rarely (every hour or more), send one or a few messages, and sleep. The HTTP connection overhead is amortized over a single useful message anyway.

Modern HTTP/2 and HTTP/3 substantially reduce HTTP's overhead vs HTTP/1.1:

• HTTP/2: Multiplexing, header compression (HPACK). Many requests over one TCP+TLS connection.
• HTTP/3 (QUIC): 0-RTT resumption (sub-handshake latency for repeat connections). UDP-based, eliminates TCP head-of-line blocking. Tolerates IP changes.

HTTP/3 in particular closes much of the gap with MQTT for persistent IoT use cases, and provides better internet traversal than CoAP.

Network type considerations

Cellular IoT (LTE-M, NB-IoT)

Battery life dominates. Devices sleep with Power Save Mode (PSM) or eDRX, waking briefly to send data. MQTT's persistent connection conflicts with PSM. Two common patterns:

• HTTP per wake-up: connect, POST, sleep. Simpler power model.
• CoAP per wake-up: send UDP packet, get response, sleep. Lowest overhead per transaction.

If the device must be reachable for commands while asleep, MQTT's PSM-aware ping intervals (long keep-alives) can work — typically 5-30 minute keep-alives.

WiFi IoT

Power is generally less constrained. MQTT is the typical default. HTTP is fine when commands are not needed.

Mesh networks (6LoWPAN, Thread, Zigbee Pro)

CoAP is the natural fit. Mesh networks were designed assuming UDP-based protocols; routing TCP through many hops is fragile.

LoRaWAN, Sigfox

Bandwidth is so limited (12 bytes per Sigfox message, 51-242 byte LoRaWAN payloads) that all three protocols become impractical. Custom binary protocols on top of LoRaWAN frames are common, with the LoRaWAN Network Server translating to MQTT or HTTP for the application layer.

Security implications

All three protocols support TLS-equivalent encryption. The implementation effort and overhead differ:

• HTTP over TLS — universal. Every TLS library supports it. Memory cost: ~30-50 KB for embedded TLS stacks.
• MQTT over TLS — same TLS as HTTPS. The persistent connection means TLS handshake cost is paid once per device lifetime.
• CoAP over DTLS — DTLS is TLS over UDP. Memory similar to TLS. Less mature, fewer libraries, more interop issues than TLS.

For new designs targeting constrained devices, CoAP over DTLS is the most weight-efficient but the most operationally complex. CoAP over TCP+TLS (RFC 8323) trades some efficiency for easier internet traversal.

Bandwidth and energy comparison

Concrete numbers for sending a single 50-byte JSON sensor reading and receiving a 10-byte acknowledgment:

The numbers shift dramatically based on whether connections are reused. A device sending one message per hour effectively pays the new-connection cost every time. A device sending continuous data pays it once.

Operational considerations

MQTT requires a broker

Operating an MQTT broker is real work — capacity planning, HA, monitoring, certificate management. Managed brokers (AWS IoT Core, etc.) remove this burden but add per-message cost.

HTTP works with anything

Backend services already speak HTTP. Adding an HTTP-based IoT endpoint is just adding another API. No additional infrastructure.

CoAP usually needs a gateway

Few backend systems natively speak CoAP. Production deployments typically run a CoAP-to-HTTP or CoAP-to-MQTT gateway at the network edge. The gateway is another component to operate.

Hybrid patterns

Real systems often combine protocols:

• CoAP on devices, MQTT at gateway. Constrained devices speak CoAP to a local gateway, which translates to MQTT for cloud transport.
• MQTT for commands, HTTP for telemetry. Long-lived MQTT subscription receives commands; periodic HTTP POSTs send batched telemetry.
• HTTP for provisioning, MQTT for operation. First boot uses HTTP for one-time provisioning (download certificate, configure broker); subsequent operation uses MQTT.
• WebSocket-tunneled MQTT for browsers. The web dashboard uses MQTT-over-WebSocket on port 443 to subscribe to the same broker as devices.

Frequently Asked Questions

What is CoAP?

CoAP (Constrained Application Protocol, RFC 7252) is an HTTP-like protocol designed for constrained IoT devices. It uses RESTful semantics — GET, PUT, POST, DELETE — but runs over UDP instead of TCP, with a 4-byte header instead of HTTP's much larger headers. Designed for devices with as little as 10 KB of RAM. CoAP is dominant in mesh-IPv6 environments like 6LoWPAN; less common in mainstream cellular IoT where MQTT prevails.

When should I use HTTP for IoT instead of MQTT?

HTTP is the right choice when: (1) the device wakes up rarely (every hour or less) — connection-setup cost is amortized over a single message anyway; (2) the device only sends data and never receives commands — no need for a persistent connection; (3) the backend is HTTP-only and you cannot run a broker; (4) the device must work behind restrictive firewalls that block non-standard ports. HTTP's larger overhead doesn't matter if the device is awake for milliseconds per hour.

Is CoAP faster than HTTP?

For small messages, yes — substantially. CoAP eliminates the TCP three-way handshake (UDP is connectionless) and uses a 4-byte header vs HTTP's typical hundreds of bytes. A CoAP GET-and-response can complete in 2 packets totaling under 100 bytes; an HTTP equivalent typically requires 5+ packets and 1+ KB. For battery-constrained devices on slow networks (NB-IoT, LoRaWAN), the time-on-air and energy-per-message difference is significant.

Does CoAP work over the public internet?

Yes but with friction. CoAP uses UDP, which many corporate firewalls and home NATs handle unreliably for inbound traffic. NAT timeout (typically 30 seconds for UDP) breaks server-initiated CoAP requests. The CoAP-over-TCP and CoAP-over-WebSocket variants (RFC 8323) address these by running CoAP semantics over TCP-based transports for internet traversal. Pure UDP CoAP works best on managed networks (cellular IoT, private mesh networks).

Can I use HTTP/2 or HTTP/3 for IoT?

Yes, and increasingly common. HTTP/2 keeps the same semantics as HTTP/1.1 but adds multiplexing — many requests over one connection. This makes it more comparable to MQTT in connection overhead. HTTP/3 over QUIC has even lower handshake latency (0-RTT for resumed sessions) and works over UDP, eliminating TCP head-of-line blocking. For devices that already have to do TLS anyway, HTTP/2 or HTTP/3 is a viable alternative to MQTT for many use cases.