MQTT vs HTTP for IoT: Which Protocol Should You Use?

HTTP runs the web; MQTT was designed for machines on unreliable networks. Both run over TCP, both can be secured with TLS, and both can carry JSON. The difference is in the communication model — and that model decides which one fits your IoT workload. This article compares them honestly, including where HTTP is the better choice.

Two different communication models

HTTP is request/response. A client asks a specific server for a specific resource and waits for the answer. The server cannot speak first: if a device needs to learn about a change, it has to poll, hold a long request open, or use an extra mechanism such as server-sent events or WebSockets.

MQTT is publish/subscribe. Clients connect to a broker and keep the connection open. Publishers send messages to topics; the broker pushes them to every subscriber of that topic. Senders and receivers never need to know about each other. If you are new to the model, read what is MQTT first.

MQTT vs HTTP comparison

Overhead and battery life

A minimal MQTT packet such as PINGREQ is just 2 bytes, and a publish adds only the topic name and payload to a small header. An HTTP request carries a method line, a host header and often user-agent, content-type, authorization and cookie headers — as text, on every request. When a sensor sends a 20-byte reading every few seconds, that framing dominates the traffic.

Connection setup matters even more. Each new HTTPS connection costs a TCP and TLS handshake, which means radio time and battery on a cellular device. MQTT pays that cost once and then reuses the connection for both directions. HTTP keep-alive and HTTP/2 narrow the gap, but they do not give the server a way to push to the device.

Reliability on bad networks

MQTT has delivery semantics in the protocol. QoS 1 and 2 acknowledge and retry messages, persistent sessions queue messages for clients that drop off, retained messages give a new subscriber the last known value immediately, and a Last Will tells everyone when a device disappears without saying goodbye. With HTTP, you build each of these yourself: retries, idempotency keys, a status store and a heartbeat endpoint.

Security

Both protocols rely on TLS for encryption, so neither is inherently more secure. The difference is where authorization happens. An HTTP API authenticates every request, typically with a token, and authorizes it per endpoint. An MQTT broker authenticates once at CONNECT (username/password, client certificates or, in MQTT 5, enhanced authentication) and then authorizes every publish and subscribe against topic-level access rules. A well-designed topic hierarchy is therefore part of your security model: a rule like this device may only publish to its own subtree is easy to express when topics include the device ID.

Scaling

HTTP services scale horizontally behind a load balancer because each request is independent. MQTT brokers hold state for every connected client — subscriptions, sessions, in-flight messages — so scaling to large fleets means clustering the broker or using a provider that does. On the consumer side, MQTT 5 shared subscriptions spread messages across several backend workers. Neither approach is harder overall; they just put the complexity in different places.

The same reading, two ways

curl -X POST https://api.example.com/devices/sensor-17/readings \
  -H 'Content-Type: application/json' \
  -d '{"temp":21.4}'

mosquitto_pub -h broker.emqx.io -t 'testmqtt/sensor-17/temp' -q 1 -m '{"temp":21.4}'

With HTTP, the API decides who gets the reading next. With MQTT, a dashboard, a database writer and an alerting service can all subscribe to testmqtt/+/temp without the device knowing they exist.

Subscribe to live readings in the browser

When to use MQTT

• Frequent telemetry from many devices.
• Sending commands to devices that sit behind NAT or firewalls — they connect out, the broker pushes in.
• Real-time dashboards and alerts that need push, not polling.
• Constrained hardware, metered links or battery-powered devices.
• One event consumed by several independent services.

When to use HTTP

• Querying and managing resources (device registry, settings, user accounts) with a REST API.
• Large file transfers such as firmware images, logs or camera snapshots.
• Infrequent, one-off uploads where keeping a connection open is not worth it.
• Public APIs for third parties who expect standard web tooling, caching and auth.

What about browsers?

Browsers cannot open raw MQTT connections, but MQTT runs fine over WebSockets, which begin life as an HTTP upgrade request. That gives web dashboards live push with the same topics your devices use. See MQTT over WebSockets for ports and setup.

Verdict

Pick MQTT for event-driven, many-device, bidirectional communication; pick HTTP for resource-oriented APIs and bulk transfers. If you are unsure, prototype the MQTT side in a few minutes with the online MQTT client and a public test broker before committing.

Frequently asked questions