Thread vs Zigbee vs Wi-Fi: What Each Smart Home Protocol Actually Does

Three radios show up on smart home device boxes, and the marketing around them is unusually bad. Here is what each one actually is.

Wi-Fi

The general-purpose networking you already have. Devices join your router, get an IP address, and are directly addressable. IEEE 802.11 operates in shared, licence-exempt spectrum — and that word *shared* is the important one, because every device on a channel competes for the same airtime.

Wi-Fi's advantages are real: no extra hub, high bandwidth, and it is the only one of the three that can carry a video stream. Its disadvantage is power. Keeping a Wi-Fi radio associated with an access point is expensive relative to the alternatives, which is why Wi-Fi door sensors and locks tend to be mains-powered or have disappointing battery life.

Zigbee

A low-power mesh protocol from the Connectivity Standards Alliance, which describes it as a proven, self-healing, self-organising mesh scalable to thousands of nodes, with PHY support in both 2.4 GHz and Sub-GHz bands, optimised for low power consumption to extend battery life. It uses IEEE 802.15.4 radio.

The critical architectural fact is that **Zigbee is not IP-based**. A Zigbee device has no address on your home network. It speaks Zigbee to a coordinator — a hub or bridge — which translates between the Zigbee network and your IP network. This is why every Zigbee ecosystem you have met required a branded bridge.

Thread

Also a low-power mesh, also on IEEE 802.15.4 radio, but built differently. The Thread Group describes it as using 802.15.4 on 2.4 GHz to create an IPv6-based mesh network, self-healing with no single point of failure, whose devices can run for years on a battery.

The difference that matters is stated plainly by the Thread Group: Thread devices seamlessly integrate with larger IP networks and don't need proprietary gateways or translators. The CSA makes the same point from the other side — Thread devices use the same 802.15.4 radio as Zigbee but an IP-based network stack.

Thread still needs infrastructure, and vendors are sometimes vague about this. A **Thread Border Router** connects the Thread network to Wi-Fi, Ethernet and the internet, and at least one is required. The distinction from a Zigbee bridge is that a border router *routes* IP packets rather than translating between incompatible addressing schemes. In practice border routers are built into speakers and hubs you may already own.

For scale, OpenThread (Google's reference implementation) documents a limit of 32 routers per network with up to 511 end devices per router.

Where Matter fits — and where most confusion lives

Matter is an application-layer standard, not a radio. The CSA states that Matter uses Bluetooth Low Energy for device setup and Wi-Fi, Thread and Ethernet for connecting devices.

**Zigbee is not a Matter transport.** The CSA is explicit that there is no native interoperability between Matter and Zigbee devices, and that Matter can connect technologies like Zigbee using bridges. Your Zigbee devices are not stranded — but they reach a Matter ecosystem through a bridge, not natively.

When this does not matter to you

If you are buying two smart plugs and a bulb, this entire article is irrelevant. Buy whatever your phone's ecosystem supports. Protocol choice starts to matter at roughly a dozen battery-powered devices, where Wi-Fi's power draw and your router's client count become real problems.

If you already own a working Zigbee setup, there is no technical reason to rip it out. Zigbee's mesh works and scales to thousands of nodes. The argument for Thread is not that Zigbee is bad — it is that Thread removes a translation layer and the vendor lock-in that tends to come with it.