Choosing the Right ESP32 Variant: ESP32, S2, S3, C3, and C6 Compared

"ESP32" used to mean one chip. It now names a whole family, and picking the wrong variant for a project means discovering partway through — often after wiring and flashing — that the board you bought is missing Bluetooth, has half the GPIO you expected, or can't do what a tutorial assumed a "normal" ESP32 could do. This guide breaks down the variants you'll actually run into as a maker: the original ESP32, S2, S3, C3, and C6, what's different about each, and which one fits which project — including where this site's own ATS Mini V4 and Marauder-based builds fit in.

Original ESP32 (ESP32-D0WDQ6 and variants)

The chip that started it all: dual-core Xtensa LX6, WiFi + classic Bluetooth + BLE, 30-38 GPIO depending on package, and by far the most mature software ecosystem — if a tutorial or library just says "ESP32" with no suffix, it's almost certainly written and tested against this one. It's the safe default for general projects, especially anything that needs classic Bluetooth (not just BLE), which none of the newer variants support. It's the chip behind most WiFi Marauder devboards and the general-purpose ESP32 projects across this site's electronics content.

ESP32-S2

Single-core Xtensa LX7, WiFi only — no Bluetooth at all, classic or BLE. Its standout feature is native USB OTG support, letting it act as a USB host or device without an external USB-to-serial chip. It's a narrower-purpose chip than the others here; pick it specifically when you need native USB device/host behavior and don't need Bluetooth, otherwise the lack of BLE rules it out for most sensor and IoT projects that want a phone-app pairing option.

ESP32-S3

Dual-core Xtensa LX7 with AI-oriented vector instructions, native USB OTG, more GPIO than the original ESP32 in most packages, and BLE 5 (still no classic Bluetooth). This is the variant behind the site's ATS Mini V4 and a growing share of newer dev boards including many Cheap Yellow Display (CYD) variants, thanks to its native USB and extra horsepower for driving displays and running more demanding firmware. If a project needs the original ESP32's performance class plus native USB and don't need classic Bluetooth, S3 is usually the better modern pick.

ESP32-C3

Single-core RISC-V (a real architecture change from the Xtensa cores above), WiFi + BLE only, fewer GPIO, and the cheapest of the family. It's popular in low-cost sensor nodes and simple IoT devices where cost and power efficiency matter more than raw processing headroom or pin count. The RISC-V core also means it uses a slightly different toolchain path in some build systems, though Arduino IDE and PlatformIO both support it directly now.

ESP32-C6

RISC-V core, WiFi 6, Bluetooth 5 (LE), and native 802.15.4 radio support for Thread and Zigbee — the variant built specifically for Matter/smart-home protocols that need a low-power mesh radio alongside WiFi. If a project is specifically a Zigbee or Thread device (rather than a WiFi/BLE device that happens to talk to Home Assistant over MQTT), the C6 is the only chip in this list with the right radio hardware built in; see our Zigbee/Z-Wave on Raspberry Pi guide for the coordinator side of that picture.

VariantCores/ArchWiFiBluetoothNative USBTypical GPIOBest For ESP32 (original)Dual Xtensa LX6YesClassic + BLENo30-38General projects, classic BT audio/HID, widest library support ESP32-S2Single Xtensa LX7YesNoneYes~43USB host/device projects, no Bluetooth needed ESP32-S3Dual Xtensa LX7YesBLE onlyYes~45Displays, AI/vision, ATS Mini-class projects, modern default ESP32-C3Single RISC-VYesBLE onlyYes (some boards)~22Cheap simple sensor nodes, low power ESP32-C6Single RISC-VYes (WiFi 6)BLE 5Yes~30Thread/Zigbee/Matter smart-home devices

Which One for Your Project

Following a tutorial that just says "ESP32" — use the original ESP32 unless the tutorial explicitly calls out a variant; library compatibility is the deciding factor more often than raw specs.
Need classic Bluetooth (Bluetooth audio, some HID use cases) — only the original ESP32 supports it; every newer variant dropped classic BT in favor of BLE-only.
Driving a display or doing camera/vision work — S3, for the extra performance and native USB flashing/debugging convenience.
Cheapest possible WiFi+BLE sensor node — C3.
Building a Zigbee or Thread device — C6, it's the only one with the right radio.
Need USB host mode (reading a USB keyboard, acting as a USB hub) — S2 or S3, both have native USB OTG the original ESP32 lacks entirely.

Toolchain and Flashing Differences

Arduino IDE's board manager treats each variant as a separate board entry — selecting the wrong one compiles against the wrong core and either fails outright or produces a binary that boots into a crash loop. RISC-V variants (C3, C6) sometimes lag slightly behind Xtensa variants in third-party library support, since a library using inline Xtensa assembly for performance-critical sections needs a separate RISC-V code path that not every library author has written. Boot-mode strapping pins also differ slightly across variants — if a board isn't entering flash mode the way an old ESP32 tutorial describes (hold BOOT, tap EN), check that variant's specific datasheet for its strapping pin behavior rather than assuming it matches the classic ESP32 exactly, since S2/S3's native USB changes how some boards handle auto-reset during flashing.

The right variant is almost always determined by one specific requirement — classic Bluetooth, native USB, Zigbee/Thread radio, or rock-bottom cost — rather than a general "which is better" comparison. Match the variant to that one requirement first, and the rest of the spec sheet differences rarely end up mattering as much as library support and board availability do in practice.

Related Guides

Loading_