Articles · October 19, 2026
MQTT vs HTTP vs WebSockets vs CoAP: which protocol for your IoT project?
Every connected device needs a way to send data and receive commands. Four protocols come up again and again: MQTT, HTTP, WebSockets and CoAP. They solve different problems, and picking the right one saves battery, bandwidth and code.
The four in one table
| MQTT | HTTP | WebSockets | CoAP | |
|---|---|---|---|---|
| Model | Publish/subscribe via a broker | Request/response | Two-way stream | Request/response, plus observe |
| Transport | TCP (TLS) or WebSockets | TCP (TLS) | TCP (TLS) | UDP (DTLS) |
| Server can push | Yes | No (polling) | Yes | Yes, with observe |
| Header overhead | 2 bytes minimum | Hundreds of bytes | 2 to 14 bytes per frame | 4 bytes |
| Delivery guarantees | QoS 0, 1, 2 | Your own retries | Your own | Confirmable messages |
| Best at | Many devices, many readers | APIs, one-off uploads | Browsers, live UIs | Constrained networks |
MQTT: built for telemetry
MQTT devices connect to a broker and publish messages to topics such as home/kitchen/temp. Anything interested subscribes, including wildcards like home/+/temp. Publishers and subscribers never need to know about each other.
That decoupling is why MQTT dominates IoT. A sensor publishes once and the broker fans the message out to your dashboard, Home Assistant and a logger. The connection stays open, so commands reach the device instantly with no polling. QoS levels let you choose between fire-and-forget and guaranteed delivery, and retained messages give new subscribers the last known value immediately. Last will messages tell everyone when a device drops off unexpectedly.
The cost: you need a broker. That is where a hosted service like mqtty comes in. It is free for small projects, so you don't have to run Mosquitto yourself.
HTTP: simple, but chatty
HTTP is everywhere and every platform has a client. For a device that uploads one reading an hour and sleeps, a plain HTTPS POST is perfectly fine. Where it hurts is anything live: the server cannot reach the device, so commands mean polling, and every request carries headers and often a new TLS handshake. That is expensive on a battery.
WebSockets: MQTT's best friend in the browser
WebSockets give a browser a long-lived, two-way connection. On their own they are just a pipe, and you design the messages. In practice, the most common way to use them in IoT is MQTT over WebSockets: your web dashboard speaks MQTT to the same broker as your devices. mqtty supports that out of the box at wss://broker.mqtty.com:8884/mqtt, so a library like MQTT.js can subscribe to your topics directly from a web page.
CoAP: HTTP for tiny devices
CoAP (Constrained Application Protocol) brings REST-style GET/PUT/POST to devices on lossy, low-power networks, running over UDP with DTLS. Its observe option lets clients get updates without polling. CoAP shines on 6LoWPAN and Thread networks and very constrained microcontrollers, but tooling is thinner and many home networks and clouds are built around TCP.
So which one?
- Sensors and actuators talking to dashboards, home automation or each other: MQTT.
- A device that wakes up, uploads a file and sleeps: HTTP.
- A browser UI that shows live device data: MQTT over WebSockets.
- Battery devices on a constrained mesh network: CoAP, or MQTT-SN through a gateway.
For most ESP32, Raspberry Pi and Home Assistant projects, the answer is MQTT. You can get a free MQTT broker at mqtty and have a device publishing in a few minutes, with every message visible in a live dashboard and kept for 60 days.
mqtty gives every account 6 devices, 30 messages per minute and 60 days of history, with TLS and a live dashboard.
Start free with mqtty →