Why most ESP32 guides are already out of date
If you've searched "ESP32 variants comparison" in the last six months, you've likely landed on articles that treat the original dual-core Xtensa chip as the headline and bolt on a half-page about the S2 as an afterthought. The embedded world has moved fast. Espressif's current lineup is a genuinely different family — RISC-V cores, IEEE 802.15.4 radios, Wi-Fi 6 support, and a vector co-processor capable of running lightweight neural nets. Choosing the wrong variant at design time can mean a board respin or, worse, shipping a product that can't meet your connectivity requirements for the next five years.
At DigitalMonk we've built and shipped products on the S3, C6, and C3. We've learned which variant fits which constraint. This is that guide — written from PCB bring-up, not benchmarks lifted from a datasheet.
Scope note: This article focuses on the four variants with active production momentum in 2025: ESP32-S3, ESP32-C6, ESP32-H2, and ESP32-C3. The original ESP32 and S2 are still available and covered briefly where relevant, but they are legacy choices for new designs.
The master comparison table
Numbers first, context second. Here is every meaningful spec side by side — the kind of table you'd normally have to assemble yourself from four separate Espressif datasheets.
| Feature | ESP32-S3 | ESP32-C6 | ESP32-H2 | ESP32-C3 |
|---|---|---|---|---|
| CPU Architecture | Xtensa LX7 dual-core | RISC-V single-core | RISC-V single-core | RISC-V single-core |
| Max CPU Speed | 240 MHz | 160 MHz | 96 MHz | 160 MHz |
| SRAM | 512 KB | 512 KB | 320 KB | 400 KB |
| Wi-Fi | Wi-Fi 4 (802.11n) | Wi-Fi 6 (802.11ax) | None | Wi-Fi 4 (802.11n) |
| Bluetooth | BT 5.0 + BLE | BLE 5.0 | BLE 5.4 | BLE 5.0 |
| IEEE 802.15.4 (Thread/Zigbee) | ✗ None | ✓ Thread + Zigbee | ✓ Thread + Zigbee | ✗ None |
| Matter-Ready (native) | No (needs co-processor) | Yes (native) | Yes (native) | No |
| AI / Vector Extension | PIE (vector ops) | None | None | None |
| USB OTG | Yes (full-speed) | No | No | No (USB-Serial only) |
| Camera Interface (DVP) | Yes | No | No | No |
| Typical Deep Sleep Current | ~7 µA | ~5 µA | ~8 µA | ~5 µA |
| ADC Channels | 20 × 12-bit | 7 × 12-bit | 5 × 12-bit | 6 × 12-bit |
| Module Cost (approx, USD) | $2.50–$4.00 | $2.00–$3.00 | $1.80–$2.80 | $1.20–$1.80 |
| Flash (typical module) | 8 MB – 16 MB | 4 MB – 8 MB | 4 MB | 4 MB |
| Best For | Vision, AI, HMI | Smart home, Wi-Fi 6 | Mesh, border router | Budget, simple IoT |
What each chip actually gives you
The powerhouse of the family. Two Xtensa LX7 cores at 240 MHz, plus Espressif's PIE vector extension that accelerates matrix multiplications, convolutions, and DSP operations. If your product has a camera, a local ML model, or a colour display, this is your chip.
- CPUDual Xtensa LX7 @ 240 MHz
- AI AccelPIE vector extension
- USBFull-speed OTG (built-in)
- WirelessWi-Fi 4 + BT 5.0 + BLE
- GPIO45 pins
- CameraDVP + JPEG encoder
The connectivity specialist. First Espressif chip to support Wi-Fi 6 (802.11ax) and the only one combining Wi-Fi, BLE, and IEEE 802.15.4 on a single die — the natural choice for Matter devices and dense smart home deployments.
- CPUSingle RISC-V @ 160 MHz
- Wi-FiWi-Fi 6 (802.11ax)
- Sub-GHz802.15.4 (Thread + Zigbee)
- MatterNative support
- Low Power~5 µA deep sleep
- GPIO23 pins
No Wi-Fi, by design. The H2 is a pure IEEE 802.15.4 + BLE 5.4 chip — ideal as a mesh coordinator, Zigbee end-device, or the radio half of a Thread border router paired with an S3 or C6 for IP backhaul.
- CPUSingle RISC-V @ 96 MHz
- Wi-FiNone
- Sub-GHz802.15.4 (Thread + Zigbee)
- BLE5.4 (latest standard)
- SRAM320 KB
- Best RoleMesh node / coordinator
The value play. Single RISC-V core, Wi-Fi 4, BLE 5.0, and a sub-$2 module price. No camera, no AI extension, no 802.15.4 — but for a smart plug or basic MQTT device it's completely capable.
- CPUSingle RISC-V @ 160 MHz
- Wi-FiWi-Fi 4 (802.11n)
- BLE5.0
- SRAM400 KB
- Module cost~$1.20–$1.80
- Best RoleBudget sensor / BLE bridge
The radio stack matters more than the CPU
When engineers ask us which ESP32 to use, the first question we ask back is: what protocol does your product need to speak in five years? CPU speed is rarely the bottleneck — the radio stack defines your product's compatibility with the ecosystem it lives in.
Wi-Fi 6 and why it matters for dense deployments
The C6 is the only ESP32 with Wi-Fi 6 support. The practical difference isn't raw speed — it's OFDMA (orthogonal frequency-division multiple access), which lets an access point schedule multiple devices in the same channel simultaneously. In a home with 40+ IoT devices, this translates to consistent latency and fewer dropped updates. If you're building smart home appliances targeting the 2025–2030 market, Wi-Fi 6 compatibility is becoming table-stakes.
Thread, Zigbee, and the Matter equation
Thread is an IPv6-based mesh protocol that runs on IEEE 802.15.4 — the same physical layer as Zigbee. Both the C6 and H2 have an 802.15.4 radio built in. The C6 also has Wi-Fi, making it a natural Matter over Wi-Fi device, while the H2 is optimised for Thread mesh nodes and Zigbee end-devices where battery life is critical.
Matter compatibility at a glance: Matter over Wi-Fi works on the S3, C6, and C3 (with a Thread border router upstream). Matter over Thread requires the C6 or H2. If your product needs to work natively in Apple Home, Google Home, or Amazon Alexa without a hub, the C6 is currently the cleanest single-chip solution.
| Protocol | ESP32-S3 | ESP32-C6 | ESP32-H2 | ESP32-C3 |
|---|---|---|---|---|
| Wi-Fi 4 (802.11n) | ✓ | ✗ | ✗ | ✓ |
| Wi-Fi 6 (802.11ax) | ✗ | ✓ | ✗ | ✗ |
| BLE 5.0+ | ✓ (5.0) | ✓ (5.0) | ✓ (5.4) | ✓ (5.0) |
| IEEE 802.15.4 | ✗ | ✓ | ✓ | ✗ |
| Thread (Matter) | ✗ | ✓ Native | ✓ Native | ✗ |
| Zigbee | ✗ | ✓ | ✓ | ✗ |
| Matter over Wi-Fi | ⚠ Via cloud | ✓ Native | ✗ No Wi-Fi | ⚠ Via cloud |
| Bluetooth Classic | ✓ | ✗ | ✗ | ✗ |
Need to pick the right chip for your product?
Our ESP32 engineers have shipped products on every variant. One call saves weeks of re-spin time.
ESP32-S3 and the case for on-device ML
The S3's PIE (Processor Instruction Extensions) vector unit is a hardware accelerator that operates on 128-bit SIMD registers. In practical terms, it runs TensorFlow Lite Micro models 5–10× faster than a standard Xtensa core alone — enough to do wake-word detection, image classification at low resolution (96×96, 128×128), or simple gesture recognition from an IMU without any cloud round-trip.
We've deployed the S3 in wearable fitness trackers doing rep counting and in machine-vision units doing basic defect detection on a production line. In both cases, the S3 handled inference locally with latency under 80 ms — fast enough to feel real-time to the user, and completely offline-capable.
What the S3 cannot do (and where you need a dedicated NPU)
The PIE vector extension is not a neural processing unit. It does not have dedicated MAC arrays or SRAM near compute. For tasks like face recognition at reasonable accuracy, pose estimation, or any model bigger than a couple of hundred kilobytes of weights, the S3 will struggle or require an external NPU (Kendryte K210, Himax HX6537, or similar). Know your inference budget before committing.
DigitalMonk rule of thumb: If your TFLite model is under 256 KB of weights and your input resolution is under 128×128, the S3 handles it comfortably. Larger than that — scope a dual-chip design with a dedicated NPU. We've done both; the difference in power and BOM cost is significant.
Deep sleep numbers and what they mean for battery products
Raw deep-sleep current is only part of the story. Wake latency, how long the radio takes to associate, and your duty cycle all interact to determine actual battery life. Here is how each variant performs in a typical sensor duty-cycle scenario: wake every 5 minutes, take a reading, transmit one MQTT packet, sleep.
| Variant | Deep Sleep | Active (CPU only) | TX Peak (Wi-Fi) | Wake Latency | Battery (2500 mAh, typical cycle) |
|---|---|---|---|---|---|
| ESP32-S3 | ~7 µA | ~30–70 mA | ~250 mA | ~120 ms | ~8–12 months |
| ESP32-C6 | ~5 µA | ~20–50 mA | ~250 mA (Wi-Fi 6) | ~100 ms | ~10–14 months |
| ESP32-H2 | ~8 µA | ~15–30 mA | ~30 mA (802.15.4) | ~60 ms | >24 months |
| ESP32-C3 | ~5 µA | ~20–50 mA | ~240 mA | ~100 ms | ~10–14 months |
The H2's dramatically better battery figure comes from the 802.15.4 radio's inherently lower TX power compared to Wi-Fi. If your product is mains-powered or recharged regularly, the H2's power advantage is irrelevant. If it runs on two AA cells and lives in a wall sensor that nobody ever wants to open, the H2 changes the economics of your product entirely.
Real project context: On a building automation mesh sensor project we shipped using the H2, we estimated over 3 years of operation from a pair of lithium AAs on a 10-minute data interval. That's the kind of number that makes installers and building managers choose your device over the competition.
How to choose in under 60 seconds
Run through these conditions top to bottom. The first match is your answer.
⚡ Variant Selection Guide
Peripheral comparison for hardware designers
GPIO count and peripheral set determine how much external glue logic your board needs. The S3 has by far the most pins; the H2 is the most constrained. Here's the breakdown for hardware designers evaluating BOM and board area:
| Peripheral | ESP32-S3 | ESP32-C6 | ESP32-H2 | ESP32-C3 |
|---|---|---|---|---|
| Total GPIO | 45 | 23 | 27 | 22 |
| ADC Channels (12-bit) | 20 | 7 | 5 | 6 |
| SPI (controllers) | 4 | 2 | 2 | 3 |
| I²C (controllers) | 2 | 2 | 2 | 1 |
| I²S | 2 | 1 | None | 1 |
| UART | 3 | 2 | 2 | 2 |
| PWM (LEDC ch.) | 16 | 6 | 6 | 6 |
| USB OTG | Yes (FS) | No | No | No |
| Camera (DVP) | Yes | No | No | No |
| LCD Interface | Yes (8/16-bit) | No | No | No |
| Temperature Sensor | Yes | Yes | Yes | Yes |
| Dedicated LP Core | Yes (ULP) | Yes (LP core) | No | No |
ADC accuracy caveat: Espressif's ADC has known non-linearity, particularly on pins shared with Wi-Fi. On every variant, avoid using ADC channels during active Wi-Fi transmission — the noise floor rises significantly. Use external ADCs (ADS1115, MCP3421) for any precision measurement application. We've seen this bite teams on production boards where Wi-Fi polling and ADC sampling weren't isolated in firmware.
Real product categories matched to variants
| Product Category | Recommended Variant | Key Reason |
|---|---|---|
| Smart camera / doorbell | ESP32-S3 | DVP camera interface, JPEG encoder, PIE for object detection |
| Matter smart plug / switch | ESP32-C6 | Native Matter over Wi-Fi 6, no hub needed |
| Zigbee end-device sensor | ESP32-H2 | 802.15.4 radio, multi-year battery life |
| Thread border router | ESP32-C6 | Single chip with both Wi-Fi 6 and 802.15.4 |
| Wearable / fitness tracker | ESP32-S3 | BT Classic + BLE, PIE for sensor fusion |
| Basic MQTT sensor node | ESP32-C3 | Lowest cost, sufficient for simple Wi-Fi/BLE tasks |
| Industrial HMI panel | ESP32-S3 | LCD interface, USB OTG, large GPIO count |
| BLE beacon / asset tracker | ESP32-C3 | Low cost, BLE 5.0, simple firmware needs |
| Mesh lighting system | ESP32-H2 | Zigbee mesh, low active power |
| Audio streaming device | ESP32-S3 | Only variant with I²S + Bluetooth Classic for A2DP |
| Vending machine controller | ESP32-S3 | GPIO count, display support, USB, Wi-Fi + BLE concurrently |
| Smart energy meter | ESP32-C6 | Matter certified, Wi-Fi 6, secure boot, AES acceleration |
What the development ecosystem looks like in 2025
All four variants are supported under ESP-IDF 5.x, Espressif's primary SDK. Arduino support exists for the S3 and C3 (via arduino-esp32), is maturing for the C6, and is still limited for the H2. If your firmware team is Arduino-first, factor that into the C6 and H2 timeline — plan for ESP-IDF development and add 20–30% schedule buffer for the radio stack bringup.
The Matter SDK (esp-matter) is actively maintained by Espressif and is the clearest path to Matter certification for the C6 and H2. We've used it in production — the main complexity is the commissioning flow and the certificate provisioning pipeline during manufacturing, not the firmware itself.
Security note: All current variants include a hardware cryptographic accelerator (AES-128/256, SHA, RSA, ECC), secure boot, and flash encryption. The C6 and H2 also include a hardware random number generator meeting NIST SP 800-90B requirements. Enable secure boot from day one — retrofitting it post-manufacture is expensive.
Module pricing and what it means at volume
Module prices are a moving target, but the relative positioning is stable. At 10K unit volumes from Mouser or DigiKey, expect these rough ranges as of Q2 2025:
| Module | 100 units | 1,000 units | 10,000 units | Key BOM Note |
|---|---|---|---|---|
| ESP32-S3-WROOM-1 | ~$3.80 | ~$2.90 | ~$2.30 | Includes 8 MB Flash, antenna |
| ESP32-C6-WROOM-1 | ~$2.80 | ~$2.20 | ~$1.90 | 4 MB Flash, Wi-Fi 6 + 802.15.4 |
| ESP32-H2-MINI-1 | ~$2.40 | ~$1.90 | ~$1.65 | 4 MB Flash, no Wi-Fi |
| ESP32-C3-MINI-1 | ~$1.80 | ~$1.45 | ~$1.20 | 4 MB Flash, cheapest option |
The delta between C3 and S3 at 10K units is roughly $1.10 per board. If your margin model is thin — e.g. a high-volume consumer product at a $15 retail price — that matters. If you're building a $500 industrial device, choose on capability and move on. We've seen teams underpick silicon to save $0.80 and then spend $30,000 in engineering time trying to make it work. Pick the right chip first.
Not sure which variant is right for your product?
We've shipped products on every variant in this guide — cameras, mesh sensors, vending machines, wearables. Talk to one of our engineers before you commit to silicon.
The short version
Espressif's current lineup is not a family of similar chips with minor speed differences. The S3, C6, H2, and C3 have genuinely different radio stacks, CPU architectures, and peripheral sets that make each one the right answer for a specific class of product.
Use the S3 when you need compute headroom, a camera, or Bluetooth Classic. Use the C6 when you need Wi-Fi 6 and native Matter over a single die. Use the H2 when battery life is the design constraint and Wi-Fi is unnecessary. Use the C3 when you need to hit a price point and Wi-Fi + BLE is sufficient.
If the answer still isn't obvious after reading this, it usually means the product requirements haven't been fully resolved — and that's actually the most useful thing we can tell you. A chip selection conversation is really a product requirements conversation in disguise. Our team at DigitalMonk does this every day. Start with a conversation →
Related reads: Explore our embedded product development work — from BLE wearables and vending machine controllers to industrial sensor networks. If you're evaluating our team for end-to-end delivery, our embedded product development services page covers the full scope from concept to manufacture.
