MQTT vs HTTP: What's the Difference, and Which Should You Use for IoT?

HTTP traditionally follows a client-initiated request/response model: a client sends a request, and a server returns a response. MQTT uses publish/subscribe, where messages are routed through a broker by topic, and the two sides do not need to know each other's address. Fetching a resource is HTTP work. Streaming changing state from many devices is MQTT work.

Both protocols move bytes between machines. They disagree about almost everything else: who is allowed to start a conversation, how much ceremony each message carries, and what happens when the network drops. That disagreement is why one is the right answer for a REST API and the wrong answer for ten thousand battery-powered sensors.

1. The short answer — a phone call vs. a bulletin board

Two analogies will carry you through the rest of this article.

HTTP is a phone call. Someone has to dial. You say something, the other side answers, then you hang up. The far end cannot call you — it only ever responds. In traditional HTTP, every exchange exists because a client decided to start it.

MQTT is a bulletin board. You pin a message to the board and walk away. You do not know who reads it. Anyone who cares about that category of message watches the board themselves.

Do not push the analogy too far, though. MQTT does not make the two sides invisible to each other — it makes them independent. Publishers and subscribers do not need to know each other's network address or identity, which is a weaker and more accurate claim than "they never see each other." A single client is very often both a publisher and a subscriber at the same time, and the broker does hold per-client state: the session, the subscriptions, the retained messages.

Here is the whole article in one table. If you screenshot anything, screenshot this.

The ports are worth splitting out, because they confuse people later:

2. Quick decision guide — which one do you actually need?

If you are here to make a decision rather than to read a comparison, start here.

If you are still unsure, the tie-breaker is who needs to speak first. If the answer is "the server needs to reach many connected devices reliably", MQTT is usually the better fit. If the answer is "the user, on demand", HTTP is usually the simpler fit.

Most real systems end up using both. Section 9 shows where the line usually falls.

3. How HTTP works — request, response, and nothing else

Every HTTP exchange has the same four-part shape: a start line, a set of header fields, a blank line, then an optional body. Requests and responses are structurally identical — only the start line differs.

Two properties of this design matter for the comparison.

HTTP is stateless. Each request carries everything the server needs to understand it. The server does not remember your last question. That is why sessions, cookies, and bearer tokens exist — they are the workaround for statelessness, not a feature of it.

HTTP has method semantics. The method tells the server what kind of operation this is, and two properties follow from it:

Safe means the method does not change server state — which is why using GET to delete something is a classic production incident. Idempotent means sending the same request once and sending it ten times leave the server in the same final state. Note that idempotent does not mean "no side effects": deleting a resource that is already deleted still results in a deleted resource, so DELETE is idempotent.

Keep that table in mind. It becomes important in §7, when we look at what you have to build yourself on top of HTTP to get reliable delivery.

One correction before we go further

You will read, in a lot of comparison articles, that "HTTP cannot push." That is wrong, and it is worth correcting because it is the most common inaccuracy in this whole debate.

Traditional HTTP follows a client-initiated request/response model. The client sends a request; the server answers. The server has no way to originate a message on its own. But the HTTP ecosystem has grown several mechanisms that give it push-like behaviour anyway:

• Server-Sent Events (SSE) — a response that stays open and streams events to the browser
• WebSocket — an upgrade performed over HTTP, after which the connection is bidirectional
• HTTP streaming — a response body that simply never ends, which is what SSE formalises
• HTTP/2 server push — a historical mechanism that has since been largely deprecated

So the accurate statement is: HTTP has no built-in push primitive, and every push-like behaviour on HTTP is a workaround built on top of a request/response protocol. That distinction — no primitive, versus no possibility — is the one worth carrying into the rest of this article.

4. How MQTT works — broker, topics, and decoupling

MQTT has three roles. A publisher sends a message to a topic. A subscriber declares interest in a topic or a pattern of topics. A broker sits in the middle and does the routing.

MQTT lets publishers and subscribers exchange data without needing to know each other's network address or identity. The broker handles the routing. That is decoupling, not invisibility — and the difference is practical: a single client is often both a publisher and a subscriber, and the broker holds per-client state.

Topics and wildcards

A topic is a UTF-8 string with a slash-delimited hierarchy. There is no registration step — topics are created the moment someone publishes to them. Two wildcards do all the matching work: + matches exactly one level, and # matches all remaining levels.

The rules are small enough to memorise:

• home/room1/temp matches exactly that topic
• home/+/temp matches home/room1/temp and home/room2/temp, but not home/room1/sensor/temp
• home/# matches everything below home
• # must be the last level and must occupy a level on its own — home/#/temp is invalid

That last rule matters more than it looks. It is what makes # safe to reason about, and it is also why # is dangerous in production (§12).

MQTT is not a message queue

The name is misleading, and the misunderstanding causes real design mistakes.

In a message queue, each message waits until exactly one consumer picks it up, and work is distributed across consumers. In MQTT, every subscriber that matches a topic receives its own full copy of the message. Ten subscribers means ten copies. If nobody is subscribed, the message is simply dropped — unless it was published as a retained message.

The "MQ" in MQTT referred to IBM's MQ Series product line, which the inventors named the protocol after. Since 2013 the specification has treated "MQTT" as a name rather than an acronym, because it stopped describing the protocol accurately.

If you do want competing consumers — several workers pulling from one stream — MQTT 5.0 adds shared subscriptions for exactly that.

Four mechanisms you will need

Those four mechanisms are why MQTT survives flaky networks without application code. HTTP gives you none of them, which is not a defect — it is a different design target.

The current version is MQTT 5.0, ratified by OASIS on 7 March 2019 and also published as ISO/IEC 20922. Version 3.1.1, from 2014, is still very widely deployed. We come back to the difference in §11.

If you want to see these mechanisms in a working system rather than a specification, our walkthrough on ESP32 Ethernet, PoE, MQTT, and Home Assistant builds one end to end.

5. The five differences that actually matter

Most comparisons list twenty differences. Five of them decide real architectures.

5.1 Communication model. HTTP is a conversation with a fixed speaker order. MQTT is a noticeboard with a broker in the middle. The practical consequence: with HTTP, the server has no way to originate a message on its own; with MQTT, it does. If your product needs to tell a device something at a moment the device did not choose, that is a hard requirement, not a preference.

5.2 Who initiates. In traditional HTTP the server is passive by construction. In MQTT either side can publish, so a backend can push a configuration change or a command to a device that is behind NAT and has no routable address. This is the difference people most often discover too late, after they have built a polling loop.

5.3 Per-message overhead. HTTP's header block is text and it is generous. MQTT's fixed header starts at two bytes. On a per-message basis the gap is roughly an order of magnitude, and it multiplies with device count — see §6 for the arithmetic.

5.4 One-to-many. With MQTT, fan-out is the broker's job: one publish, N deliveries. With HTTP, either every consumer polls the same endpoint, or you build a push layer (SSE, WebSocket) and take on its connection management yourself. Polling cost scales as consumers × poll rate, which is the multiplication nobody budgets for.

5.5 Reconnection. MQTT treats a dropped connection as normal and gives you a session that survives it: subscriptions persist, and messages queue while you are away. HTTP has no equivalent. Every reconnect is a fresh TCP and TLS handshake, and any state you needed is yours to re-establish.

6. Header overhead — where the difference actually bites

This is the section people quote, so the assumptions are stated up front.

Reference values — a scenario, not a protocol constant. The figures below assume one reading per minute, a persistent (keep-alive) TCP connection on both sides, and TLS on both. HTTP overhead is a representative request + response header pair of about 700 bytes; MQTT overhead is a 2-byte fixed header plus a short topic name, about 20 bytes. The real difference depends heavily on payload size, connection reuse, HTTP version, header compression, and authentication overhead — re-derive it for your own numbers before you make a decision on it.

One reading per minute is 1,440 messages a day. Count only the protocol overhead, not the payload:

On one device, that difference is irrelevant. On ten thousand:

Four caveats, because this comparison is easy to abuse.

1. HTTP/2 compresses headers. HPACK can reduce a repeated header set to a few bytes per request, which narrows the gap considerably. But it only helps for repeated headers on the same connection, and the device has to maintain the compression context. If your HTTP clients open a new connection per request — which is common on constrained hardware — HPACK buys you nothing. Our article on implementing HTTP/2 on ESP32 platforms covers what that costs in practice.

2. Connection reuse is the variable that decides everything. Both protocols can reuse a connection. The genuine difference is the per-message header cost, not the handshake. If your HTTP client already keeps a connection alive, the 35× figure is about headers alone.

3. MQTT's connection setup is not cheaper than HTTP's. It still costs a TCP handshake and a TLS handshake. MQTT wins on per-message cost amortised over a long-lived connection, and on its ability to queue messages while a device is offline — not on connection establishment.

4. This is a scenario, not a property of the protocols. Change the report interval, change the payload size, or move to HTTP/2 with HPACK, and the ratio moves. Read the table as "MQTT is cheaper at scale", never as "MQTT always saves 35×".

The conclusion worth keeping: MQTT's advantage scales with device count, not with message size. One device saving a megabyte a day does not matter. Ten thousand devices saving nine gigabytes a day does.

7. Reliability — QoS levels vs. retries you write yourself

MQTT makes reliability a dial instead of a guarantee you either have or do not.

The rule people get wrong

QoS is decided twice — once by the publisher on the PUBLISH packet, and once by the subscriber when it sends SUBSCRIBE. The broker delivers at the lower of the two.

A worked example makes it concrete. A sensor publishes at QoS 2. A dashboard subscribes with QoS 1. The dashboard receives the message at QoS 1. The full four-part handshake still happens between the sensor and the broker — but it is not carried all the way out to the subscriber.

Note what is being compared: the publisher's QoS against the Subscription QoS, meaning the level requested in the SUBSCRIBE packet. It is not about the subscriber's capability or the broker's configuration.

What HTTP gives you instead

Nothing, at the protocol level. HTTP is a transport for a single exchange; whether that exchange succeeded reliably is your application's problem. So you write retries — and the moment you write retries, you collide with idempotency from the table in §3. Retrying a POST can create a duplicate order. Retrying a PUT cannot, because PUT is idempotent. This is precisely why method semantics matter in practice and not just in textbooks.

The practical takeaway: QoS 1 plus deduplication on the consumer side is usually a better trade than QoS 2 everywhere. Do not reach for exactly-once delivery by default — four packets per message is a real cost, and at high report rates it is a fourfold increase in message volume.

8. When each one is the wrong choice

A comparison that never tells you to walk away is not useful.

8.1 When MQTT is the wrong choice

You are fetching a resource, not receiving a stream. Paged lists, historical queries, placing an order — these are HTTP's home ground. Modelling them as topics is awkward and you will reinvent request/response badly.

You need a browser to call it directly. MQTT over WebSocket works, but if your only client is a web page and you have no broker, HTTP or SSE is less machinery.

The interaction is one-off and stateless. Standing up a broker and a long-lived session to send one request is over-engineering.

Nobody on your team can operate a broker. This is the most underrated cost in the whole comparison. A broker is a stateful, high-availability component. When it goes down, every device goes silent at once — and that is a different failure mode from an API returning 500s. Budget for running it before you budget for the licence.

You need strict request/response semantics. MQTT 5.0 added Response Topic and Correlation Data; on 3.1.1 you build it yourself on top of two topics.

8.2 When HTTP is the wrong choice

Many devices reporting frequently. Run the arithmetic in §6 against your own fleet size before deciding this does not apply to you.

The server needs to push. Polling cost scales as device count × poll rate. SSE and WebSocket are real options, but they are layers you build and maintain — not primitives you get.

Bandwidth or power is constrained. On a metered cellular or satellite link, header overhead is money and battery. This is where the two-byte fixed header stops being trivia.

The link is unstable and devices sleep. HTTP has no built-in reconnect-and-resend. You will write it, and you will get it subtly wrong at least once.

One source, many consumers. With HTTP, ten consumers means ten polls, or a push layer you now own.

Note the phrasing throughout this section: HTTP has no built-in push primitive. It does not mean HTTP cannot push.

9. MQTT over WebSocket — and why the "vs." is often a false choice

A browser cannot open a raw TCP socket, so it cannot speak MQTT natively. MQTT over WebSocket solves that: the WebSocket handshake runs over HTTP, and the MQTT packets travel inside it. The subprotocol identifier is mqtt, and it typically rides on 443, 8083, or 8084.

That single fact is enough to dissolve most of the either/or framing. Real IoT systems are almost always mixed:

The real design question is not "which protocol", but "where do you draw the line". The usual answer: MQTT on the constrained, high-count, push-dependent edge; HTTP on the boundary you expose to the outside world, where caching and familiar tooling matter more than bytes.

This is also where the two halves of a typical IoT product meet. A LoRaWAN gateway almost always converts what it receives into MQTT before sending it upstream — the radio solves the last few kilometres, and MQTT solves the gateway-to-cloud hop. If you are working on that layer, What Is a LoRa Module? covers the hardware half.

10. Security — TLS on both, but the trust model differs

Both protocols can run over TLS. HTTPS is HTTP over TLS; MQTT over TLS conventionally uses port 8883. At the transport layer, the two are equally protected.

The difference is in authorisation.

MQTT's authorisation model is finer-grained. You can give a device permission to write to exactly its own topic and to read exactly one other. Reproducing that in HTTP means implementing it in your gateway layer, because the protocol itself has no notion of a scoped resource the way a topic ACL does.

Two warnings worth repeating:

• Port 1883 is plaintext. Do not run it in production. TLS on 8883 is the baseline, not an upgrade.
• A # subscription in production is a data breach waiting to happen. It grants read access to every topic on the broker. Topic ACLs exist to make sure it never gets granted.

11. MQTT 5.0 vs. 3.1.1 — what changed

This section is optional depth. Skip it if you only need the HTTP comparison — it does not change any conclusion in this article.

MQTT 5.0's headline theme is observability. On 3.1.1, failures were largely silent; on 5.0, the protocol tells you what went wrong.

One practical caveat: confirm that both your broker and your client library support 5.0 before committing. Support across cloud platforms and embedded SDKs is uneven.

For this article's comparison, the version does not matter. HTTP and MQTT differ at the model layer, not the version layer.

12. Common mistakes to avoid

1. Treating MQTT as a message queue. Every matching subscriber gets its own copy. If you need competing consumers, use shared subscriptions.
2. Using QoS 2 everywhere. Four packets per message. At high report rates that is a fourfold volume increase for a guarantee you probably do not need.
3. Flat topic design. Publishing to temperature123 with no hierarchy means you can never scope permissions by site or device class later. Design the tree before you ship.
4. Subscribing with # in production. It reads every topic on the broker. ACLs should make it impossible.
5. Ignoring what clean session does. With a persistent session, the broker queues messages for offline devices. A device that never comes back will fill that queue until the broker runs out of memory.
6. Running plaintext 1883. Use TLS on 8883.
7. Using HTTP polling to fake real time. You lose on latency and you lose on cost, simultaneously.
8. Forgetting keep-alive. Half-open TCP connections pile up as zombie clients and consume broker resources.
9. Comparing per-message overhead without multiplying by device count. See §6 — the advantage is a multiplier, not a constant.
10. Adopting MQTT because it is the IoT protocol. If you do not have the many-devices, push, or constrained-bandwidth requirement, HTTP is simpler to build and far simpler to operate.

13. Frequently asked questions

Is MQTT faster than HTTP — and can it replace HTTP?

"Faster" is the wrong frame; they optimise different things. MQTT has far lower per-message overhead — a two-byte fixed header against HTTP's text headers — and that advantage compounds over long-lived connections and large fleets. But it cannot replace HTTP, because it is not a request/response protocol for fetching resources. Most systems run both.

Can MQTT run in a web browser, and does it use HTTP?

Not natively — browsers cannot open raw TCP sockets. MQTT over WebSocket solves this by tunnelling MQTT packets inside a WebSocket, which itself is established via an HTTP upgrade. So the browser speaks WebSocket, not HTTP, once connected. MQTT is not an HTTP protocol; it merely borrows HTTP for the handshake.

Is MQTT a message queue?

No, and the distinction changes how you design. In a queue, each message is consumed by exactly one worker. In MQTT, every matching subscriber receives its own copy of every message. The "MQ" originally referred to IBM's MQ Series product line; since 2013 the specification treats MQTT as a name, not an acronym.

What port does MQTT use?

1883 for plaintext TCP, 8883 for MQTT over TLS, and 8083 or 8084 for MQTT over WebSocket (unencrypted and encrypted respectively). WebSocket deployments are also commonly placed on 443 to pass through corporate firewalls. Plaintext 1883 should not be exposed to the public internet.

Which is more secure, MQTT or HTTP?

At the transport layer, neither has an advantage — both run over TLS and are equally protected. The difference is authorisation granularity. MQTT grants permissions per topic and can separate publish from subscribe rights; HTTP grants them per endpoint. MQTT's model is finer-grained, but only if you actually write the ACLs.

Does MQTT work over LoRa?

Not directly. LoRa is a physical-layer modulation, and MQTT expects a reliable, ordered, bidirectional TCP connection — which a LoRa link does not provide. In practice, a LoRaWAN gateway receives the radio traffic and republishes it to an MQTT broker over a normal network connection. The two technologies meet at the gateway.

Should I use MQTT or HTTP for a battery-powered sensor?

MQTT, in most cases. The smaller per-message overhead directly extends battery life, and the persistent session means the device does not pay a TCP and TLS handshake every time it wakes to report. The exception is a device reporting a handful of times per day over an always-available link, where HTTP is simpler and the energy difference is negligible.

Can HTTP do server push without MQTT?

Yes — SSE, WebSocket, and long polling all provide push-like behaviour over HTTP. What HTTP lacks is a built-in push primitive; every one of these is a layer built on top of request/response. SSE is the lightest option for one-way server-to-client streaming and needs no broker.

14. Key takeaways

• The one-line difference: HTTP is request/response, where only the client starts an exchange; MQTT is publish/subscribe, where a broker routes by topic and either side can publish.
• Five dimensions decide real architectures: communication model, who initiates, per-message overhead, one-to-many fan-out, and reconnection behaviour.
• The overhead gap scales with fleet size. Roughly 35× in our scenario, which is about 9.4 GB against 275 MB per day at ten thousand devices — and it is a scenario value, not a protocol constant.
• QoS is decided twice, and the broker delivers at the lower of the two. Publisher QoS 2 with Subscription QoS 1 means the subscriber receives QoS 1.
• Neither protocol "pushes" or "fails to push" in absolute terms. HTTP has no built-in push primitive but several workarounds; MQTT has push natively.
• Most production systems use both. The design question is where to draw the line, not which one wins.

15. Hardware for Building MQTT-Based IoT Systems

Choosing MQTT has hardware consequences. You will need one of three kinds of device.

A gateway or bridge, if your devices do not speak IP directly. It receives radio traffic and republishes it to an MQTT broker over a normal network connection, so it needs an MCU capable of running a TCP/IP stack and a TLS client.

A node, if you are building the far end. The priorities are sleep current, radio sensitivity, and how much you want the module to do for you. A raw transceiver module gives you control; an integrated SoC module gives you one chip and a smaller bill of materials.

A development board, if you are still proving the design. An ESP32-class board with an on-board radio runs your MQTT client, sensor stack, and application logic on one board.

For developers building an MQTT-based sensor network, the hardware layer comes down to gateways, nodes, and development boards. The full range is in our LoRaWAN module collection.

Prices shown as of publication. Current price, stock and shipping options are on each product page.

Sources: OASIS MQTT Version 5.0 (ratified 7 March 2019; ISO/IEC 20922) and MQTT Version 3.1.1 (29 October 2014); RFC 9110 (HTTP Semantics), RFC 9111 (HTTP Caching), RFC 9113 (HTTP/2), RFC 9114 (HTTP/3); OASIS MQTT 5.0 shared subscriptions specification. Performance figures are indicative and depend on payload size, connection reuse, protocol version, and header compression — measure your own workload before sizing infrastructure on them.

Shop the hardware from this guide

Six picks covering the three roles above — a gateway or bridge that republishes radio traffic to an MQTT broker over IP, a node for the far end (one raw transceiver for control, one integrated SoC to shrink the bill of materials), and an ESP32-class development board for proving the design. If none of them fit, the full LoRaWAN module collection lists every variant.

Gateway / bridge · ESP32 + RS485 M5Stack Station-485 ESP32 Industrial IoT Controller RS485 Development Kit 63,53 € View product →

Gateway uplink · NB-IoT / Cat-M Waveshare SIM7070G NB-IoT / Cat-M / GPRS / GNSS HAT for Raspberry Pi 31,85 € View product →

Node · raw SX1268 transceiver (UART) Waveshare SX1268 LoRa HAT for Raspberry UART 20,85 € View product →

Node · integrated SoC + sensor LILYGO T-ECHO BME280 Meshtastic LoRa SX1262 Wireless Module nRF52840 69,95 € View product →

Dev board · ESP32-S3 + LoRa LILYGO T3 S3 Meshtastic ESP32-S3 LoRa 0.96 inch Dev Board with Antenna 26,95 € View product →

Dev board · ESP32 IoT kit M5Stack ATOM Lite ESP32 IoT M5 Development Kit 9,95 € View product →

Prices shown as of publication. Current price, stock and shipping options are on each product page.