MQTT vs CoAP vs HTTP for IoT: Which Protocol Should You Choose?
Every connected product eventually confronts the same question: how do devices actually talk to the cloud? MQTT, CoAP, and HTTP are the three application-layer protocols you will encounter most often in IoT — each suited to different constraints, data patterns, and infrastructure requirements. This post breaks them down honestly.
Why the Protocol Choice Matters
Choosing an application-layer protocol is not a cosmetic decision. It affects battery life, bandwidth cost, cloud infrastructure complexity, network resilience under drop-outs, and how easily your devices integrate with backend systems. A sensor that polls via HTTP every five seconds instead of subscribing over MQTT will drain its battery faster and generate significantly more traffic — at scale, that difference is material.
One important framing note before we compare: MQTT, CoAP, and HTTP are application-layer protocols. They sit above the transport layer (TCP or UDP) and well above the wireless physical layer. Choosing between Wi-Fi, Bluetooth LE, or LoRa is a separate decision that happens at a different layer of the stack — see our Wi-Fi vs BLE vs LoRa comparison for that discussion. You can run MQTT over Wi-Fi or over LoRa (via a gateway). You can run HTTP over an LTE connection or over Ethernet. The wireless choice and the messaging protocol choice are independent — and often more than one protocol is used within a single product at different layers.
Fig. 1 — MQTT's pub/sub model routes messages through a central broker, enabling many-to-many delivery. CoAP and HTTP use direct request/response between client and server.
MQTT: Lightweight Pub/Sub for IoT Telemetry
MQTT (Message Queuing Telemetry Transport) was designed in the late 1990s for monitoring oil pipelines over satellite links — exactly the kind of low-bandwidth, unreliable-network, battery-sensitive environment that IoT devices live in. That heritage shows in the design.
How it works
MQTT uses a publish/subscribe model mediated by a central broker. Devices (publishers) send messages to named topics — farm/sensor/03/temperature, for example. Other clients (subscribers) register interest in topics and receive matching messages the broker delivers to them. Publishers and subscribers never talk directly; the broker decouples them entirely. This many-to-many architecture is what makes MQTT exceptionally efficient for telemetry fan-out: one sensor reading goes to a dashboard, a time-series database, and an alerting service simultaneously, without the sensor knowing or caring who is listening.
MQTT runs over TCP, which gives it reliable ordering and retransmission. The protocol itself adds three Quality of Service (QoS) levels on top of that: QoS 0 (fire and forget — at-most-once delivery), QoS 1 (acknowledged delivery — at-least-once, with possible duplicates), and QoS 2 (exactly-once, using a four-step handshake). The fixed header is just 2 bytes, making it extraordinarily compact compared to HTTP.
Two additional features deserve mention for production systems: retained messages (the broker stores the last message on a topic and delivers it immediately to any new subscriber, so devices always get the current state on connect) and Last Will and Testament (LWT) (the client pre-registers a message the broker will publish automatically if the client disconnects unexpectedly — invaluable for detecting device failures without polling).
Limitations: MQTT requires broker infrastructure — you need to run or pay for a broker (Mosquitto, HiveMQ, AWS IoT Core). The persistent TCP connection means deep-sleeping battery devices pay a reconnection cost on each wakeup. And the topic hierarchy, while flexible, requires discipline to keep consistent as a fleet grows.
ESP32 devices natively support MQTT through libraries like ESP-MQTT and PubSubClient, making it a natural fit for ESP32-based IoT products. Our ESP32 developers use MQTT routinely for cloud-connected device projects.
CoAP: REST Semantics for Constrained Devices
CoAP (Constrained Application Protocol, RFC 7252) is best understood as HTTP trimmed to the bone for devices that cannot afford HTTP's overhead. It was designed specifically for machine-to-machine communication in constrained environments — devices with tens of kilobytes of RAM, battery budgets measured in microamperes, and networks like 6LoWPAN where packet sizes are tightly limited.
How it works
CoAP uses a request/response model like HTTP — GET, PUT, POST, DELETE methods that operate on resource URIs. The key difference is transport: CoAP runs over UDP, not TCP. This eliminates the TCP three-way handshake and connection state, dramatically reducing both energy cost and memory footprint. The fixed header is 4 bytes.
To handle UDP's unreliability, CoAP defines two message types: Confirmable (CON) messages require an acknowledgement from the recipient (giving you reliability at the application layer), while Non-confirmable (NON)messages are sent without expecting an ACK — suitable for frequent sensor readings where losing the occasional sample is acceptable.
CoAP also supports the Observe option (RFC 7641), which lets a client register interest in a resource and receive asynchronous notifications when that resource changes — a pub/sub-like pattern over the request/response model. It is less flexible than MQTT's topic hierarchy but covers the common case of "tell me when this sensor value updates."
Limitations: CoAP's ecosystem is smaller than MQTT's — fewer managed cloud services natively support it. Fan-out (one reading to many consumers) is not built in. The Observe mechanism, while useful, is less mature and less widely implemented than MQTT subscriptions.
HTTP: The Ubiquitous Option
HTTP needs no introduction. It is the foundation of the web and, by extension, it is the easiest protocol to integrate with cloud services, web backends, and REST APIs. For IoT, it has genuine uses — but also genuine costs that are often underestimated.
How it works
HTTP uses a request/response model over TCP. A client (device or app) sends a request to a server, the server processes it and responds, and the connection is closed (or kept alive in HTTP/1.1 keep-alive). Each request carries a full set of text headers — Content-Type, Authorization, User-Agent, and so on. In practice, HTTP headers alone are typically several hundred bytes per request, compared to MQTT's 2-byte fixed header.
For IoT, HTTP's main advantage is ubiquity. Every cloud platform exposes REST APIs. Every backend developer knows how to consume them. Firmware-over-the-air (OTA) updates delivered via HTTPS is a natural fit — files are large, encryption is mandatory, and the once-off nature means header overhead is irrelevant at that scale. HTTP is also the right choice when a device needs to call a third-party API directly, or when an IoT gateway needs to push batched data to a web endpoint.
Limitations: HTTP is expensive for high-frequency telemetry — the overhead per request is significant relative to the payload, and the TCP connection cost adds up fast on a cellular or battery-powered device. HTTP has no native push mechanism; polling is wasteful, and alternatives like WebSockets or Server-Sent Events add complexity. HTTP polling every 5 seconds from 10,000 devices generates 2 million requests per day — a number worth modelling before assuming HTTP is "simpler."
These Protocols Sit Above the Wireless Choice
A point that regularly causes confusion: MQTT, CoAP, and HTTP are application-layer protocols. They define how messages are structured and delivered between applications. Below them is the transport layer (TCP or UDP), and below that is the network and physical layer — which is where your choice of Wi-Fi, Bluetooth LE, LoRa, NB-IoT, or Ethernet actually lives.
This matters because the wireless choice and the messaging protocol choice are largely independent. You can run MQTT over Wi-Fi (the most common case), over a LoRa gateway (the gateway translates from LoRa radio frames to TCP+MQTT), or over LTE. You can run HTTP over Wi-Fi, Ethernet, or LTE. Confusing the layers leads to poorly framed questions like "should I use MQTT or LoRa?" — those are not alternatives; they are choices at different layers of the stack. Our Wi-Fi vs BLE vs LoRa post covers the wireless layer decision in detail.
Fig. 2 — MQTT and HTTP run over TCP; CoAP runs over UDP. All three sit at the application layer, above the transport layer and above the wireless/physical layer choice.
Head-to-Head Comparison
The table below summarises the key dimensions that matter when choosing an application protocol for an IoT product. No single column "wins" — the right choice is always context-dependent.
| Dimension | MQTT | CoAP | HTTP |
|---|---|---|---|
| Messaging model | Publish / Subscribe (broker-mediated, many-to-many) | Request / Response + Observe option (server push) | Request / Response (stateless, one-to-one) |
| Transport | TCP | UDP | TCP |
| Header / overhead | 2-byte fixed header — very compact binary | 4-byte fixed header — compact binary | Typically 200–800 bytes of text headers per request |
| Power efficiency | Good — persistent connection amortises cost; QoS 0 is near-zero overhead | Best at protocol level — no TCP handshake, stateless | Moderate — TCP + header overhead accumulates on frequent requests |
| Network tolerance | High — QoS 0/1/2, broker queuing, LWT for drop detection | Moderate — Confirmable/Non-confirmable, no built-in reconnect | Low — requires stable connection per request; no native retry |
| Best data pattern | High-frequency telemetry, events, fan-out to multiple consumers | Periodic reads from constrained nodes, direct device-to-server queries | Occasional requests, file / firmware transfers, API calls |
| Typical IoT use case | Sensor telemetry, device control, real-time dashboards, fleet monitoring | 6LoWPAN sensors, low-RAM MCUs, industrial M2M, standards-based deployments | OTA firmware delivery, REST API integration, batched data push |
| Broker / infra needed | Yes — MQTT broker required (Mosquitto, HiveMQ, AWS IoT Core…) | No — direct client-to-server, CoAP server on cloud side | No — any HTTP server or cloud API endpoint |
How to Choose: A Practical Decision Flow
The choice of protocol follows directly from your device constraints, data pattern, and infrastructure context. Use the flowchart below as a starting point, not a rigid rule — most production IoT systems end up using more than one protocol at different layers.
Fig. 3 — A practical starting point for protocol selection. Most IoT products use more than one protocol — the right choice depends on the specific role each protocol plays in the system.
A practical note on combining protocols: it is entirely normal — and usually correct — to use more than one in a single product. An industrial monitor might use MQTT for cloud telemetry, HTTPS for OTA firmware delivery, and a local wired protocol for communicating with field instruments. Each protocol is chosen for what it does well at that specific layer.
Real-World Examples from DigitalMonk Projects
Protocol choices look abstract until you see them applied to real constraints. Here are two products from our portfolio where the messaging protocol choice was deliberate.
Irrigation Monitor — MQTT for Field Sensor Telemetry
Our custom irrigation monitoring system deploys sensors across agricultural fields to track soil moisture, temperature, and valve states. These sensors send readings at regular intervals to a cloud backend that drives automated irrigation decisions and a farmer dashboard.
The messaging layer is MQTT. The reasons are textbook: field sensors are geographically distributed, connectivity is cellular (intermittent, variable quality), readings arrive frequently (every few minutes from dozens of nodes), and multiple subscribers need the data simultaneously — the time-series database, the alerting service, and the mobile dashboard all subscribe to the same topics. MQTT's QoS 1 delivery ensures readings are not silently lost during connectivity gaps, and the LWT feature lets the backend detect when a field unit goes offline. The protocol adds essentially no overhead at the scale of a temperature reading.
Smart HVAC Control — MQTT for Cloud, RS-485 for Local
Our smart HVAC control system illustrates something important: a production IoT product often uses multiple protocols at different layers, and that is not a design flaw — it is the right architecture.
In that system, the central controller communicates with the HVAC units inside the building via a wired RS-485 serial bus — a physical-layer fieldbus appropriate for reliable, short-distance communication between the controller and equipment within the same enclosure or building segment. RS-485 is a fundamentally different kind of protocol from MQTT: it is a wired electrical standard at the data link layer, commonly used with Modbus, not an application-layer messaging protocol and not an alternative to MQTT.
Above that local layer, the controller uses MQTT to publish telemetry and receive commands from the cloud — remote monitoring, schedule updates, alert thresholds. Two protocols, two distinct roles, two different layers of the same system. This is the pattern to emulate: choose the right protocol for each specific role rather than trying to make one protocol do everything.
DigitalMonk — IoT Development Services
We architect the full stack — firmware, protocol layer, cloud backend, and mobile app — and select the right protocol at each layer of your product.
Common Mistakes to Avoid
- 1HTTP polling for high-frequency telemetry
Using HTTP GET every few seconds to collect sensor readings is one of the most common and costly mismatches. Each request carries hundreds of bytes of headers for what may be a 10-byte payload. At scale, this burns bandwidth, battery, and server capacity. MQTT or — on constrained devices — CoAP is the right tool.
- 2Assuming MQTT is always the answer
MQTT is popular for good reasons, but it requires broker infrastructure. For a single device posting one reading per hour to a cloud API, HTTP is simpler, easier to debug, and perfectly efficient. Do not add broker complexity where it adds no value.
- 3Skipping TLS on MQTT
Plain MQTT (port 1883, no TLS) exposes device credentials and payload data on the network. Always run MQTT over TLS (port 8883) in production and authenticate clients properly. Most managed brokers enforce this by default; self-hosted setups need explicit configuration.
- 4No broker redundancy in production
A single MQTT broker is a single point of failure for your entire device fleet. Production deployments should run clustered brokers (HiveMQ cluster, EMQX cluster) or use a managed service with built-in availability guarantees. A broker outage means no telemetry from any device until it recovers.
- 5Ignoring QoS level selection
QoS 2 (exactly-once) is expensive — four message exchanges per publish. Most telemetry is fine with QoS 1 (at-least-once) with deduplication at the backend. Reserve QoS 2 for critical command-and-control messages where duplicates cause real problems, such as actuator commands.
Why DigitalMonk for IoT Protocol Architecture
Protocol selection is not a checkbox — it is an architectural decision that compounds through the entire product lifetime. A poor choice discovered late means firmware rewrites, cloud re-architecture, and potentially a hardware revision. We have been through this enough times on client projects to know which questions to ask up front: What is the sleep/wake cycle? What is the worst-case network quality? Who else needs this data and how fast?
Our team at DigitalMonk's IoT development practice architects the full stack — embedded firmware, protocol layer, cloud pipeline, and application — and picks the right protocol at each layer rather than defaulting to whatever is most familiar. We work across the UK, US, and India on fixed-scope engagements and long-term product partnerships.
Frequently Asked Questions
- For high-frequency telemetry and constrained networks, MQTT is the better fit — its pub/sub model and compact binary framing are far more efficient than HTTP polling. But 'better' depends on the use case. HTTP is perfectly appropriate for occasional data pushes, OTA firmware downloads, or integrating with web APIs where infrastructure simplicity matters more than packet efficiency. There is no universal answer.
- No. CoAP and MQTT solve different problems. CoAP is designed for resource-constrained devices that need RESTful semantics over UDP — it replaces HTTP in those environments, not MQTT. MQTT's pub/sub model handles fan-out (one message to many subscribers) that CoAP's request/response model doesn't natively support. You might run CoAP on a sensor node and MQTT at the gateway level for cloud delivery.
- Yes — and in most serious IoT systems, you do. A common pattern: MQTT for cloud telemetry (device → broker → backend), HTTPS for OTA firmware updates (backend → device), and a local wired protocol like RS-485 or Modbus for device-to-device communication within the same enclosure. Each protocol is chosen for its layer and role.
- MQTT itself does not mandate encryption — the underlying TCP connection can be plain or wrapped in TLS. In production, always use MQTT over TLS (port 8883), authenticate clients with certificates or username/password, and enforce topic-level permissions at the broker. Many managed brokers (AWS IoT Core, HiveMQ Cloud) handle this by default. Leaving MQTT unencrypted on a public network is a significant security gap.
- Yes — this is one of MQTT's design goals. QoS level 1 guarantees at-least-once delivery with acknowledgements; QoS level 2 guarantees exactly-once delivery. The broker stores messages during disconnections and delivers them on reconnect. The Last Will and Testament (LWT) feature lets the broker notify other clients if a device disconnects unexpectedly. These features make MQTT practical in environments with intermittent or lossy connectivity.
- CoAP over UDP generally has the lowest per-message energy cost at the protocol level, because UDP avoids the TCP handshake and connection-maintenance overhead. That said, total power consumption in IoT is dominated by radio duty cycle, not protocol overhead — a device sleeping 99% of the time with MQTT on wakeup will consume far less than a device continuously polling with CoAP. Design the sleep/wake cycle first; choose the protocol second.
- Yes. MQTT requires a central broker — there is no direct device-to-device MQTT without one. The broker is what enables pub/sub fan-out, QoS guarantees, retained messages, and LWT. Popular options include Mosquitto (open source, self-hosted), HiveMQ, and managed cloud brokers like AWS IoT Core and Azure IoT Hub. Running a broker adds infrastructure to manage, which is a real consideration for small teams.
Building a Connected Product? Let's Choose the Right Stack.
DigitalMonk architects IoT systems from the sensor to the cloud — firmware, protocol layer, backend, and app. We have shipped MQTT-based telemetry pipelines, HTTP-integrated dashboards, and multi-protocol industrial systems across the UK, US, and India.
Talk to Our IoT Team →