Which ESP32 module should I order, and how do I source it without fakes?

The variants that matter

• ESP32 (original, WROOM-32 / WROVER): dual-core Xtensa, Wi-Fi 4 + Bluetooth. The part most existing firmware, tutorials and toolchains were built around — still the default for drop-in replacement of existing boards.
• ESP32-S3: the mainstream successor — dual-core LX7 with native USB, more GPIO, vector instructions for light ML work. Choose it for new designs unless cost or certification dictates otherwise.
• ESP32-C3: single-core RISC-V, Wi-Fi 4 + BLE 5, the cost-down part. Its peripheral set and pin map differ from the classic ESP32, so firmware porting is real work when migrating.
• ESP32-C6: adds Wi-Fi 6 plus Thread and Zigbee radios — the choice when the product needs a mesh or Matter-class path, not just Wi-Fi.
• ESP32-H2: Thread/Zigbee without Wi-Fi, for battery mesh nodes. Listed for completeness; it is not a Wi-Fi part.

Reading a module part number

• Flash size rides in the suffix: N4 is 4MB, N8 is 8MB, N16 is 16MB. Firmware built for N8 does not shrink onto N4 — OTA slots and filesystems are sized at build time.
• PSRAM rides in the letter-number pair: R2 is 2MB, R8 is 8MB (R8V is the octal variant). WROVER modules carry PSRAM by design; WROOM typically does not. Camera and display firmware often hard-depends on it.
• Antenna style is a suffix too: the default PCB antenna, the U variant with an external antenna connector (IPEX), and the 1U naming on variants that change the layout. A certified product usually cannot switch antenna style without re-testing.
• The trailing E on newer modules (WROOM-32E class) marks the current module revision, not a new chip — but board layouts and keep-out areas differ slightly between revisions, so production should hold one revision per build.
• Chip or module: modules carry the crystal, flash, antenna and shielding (and most certifications); bare chips are for volume products that bring their own RF design. Repair and small-batch work should stay on modules for exactly this reason.

What to verify when sourcing

1. 01 Order by the full module name and quantity, and require the order confirmation to state it — not "ESP32-WROOM" but ESP32-WROOM-32E (N8) or ESP32-WROVER-E (N8R8). The generic family name in a quote is the first warning sign.
2. 02 On arrival, read the module with esptool: it identifies the chip and reports the flash size, and on the newer parts the embedded PSRAM appears in the detected feature list. A 4MB answer where 8MB was ordered is the downgrade pattern in one minute of work.
3. 03 Check the shield: laser-marked part number and variant against the label and the paperwork, shield soldering quality, and the antenna keep-out area. Pulled modules show their history at the shield edges and the pads.
4. 04 Ask for the date code and a photo of the actual tray or reel before dispatch — the same per-lot discipline as any screened component, applied to a module line where the clone incentive is the highest in the catalog.
5. 05 For production runs, keep one baseline variant on the BOM plus one sibling (S3 alongside classic 32, or C3 alongside C6 depending on the roadmap) so a spot gap in one variant does not stop the line while firmware ports happen.

When the variant you need is out of stock

The ESP32 family tolerates substitution poorly at the firmware level: moving between WROOM-32 and WROOM-32E is invisible, moving from classic ESP32 to C3 or S3 changes pin maps, peripheral registers and radio behavior — real engineering work, not a BOM swap. That is why the sourcing plan for ESP32 lines is depth in the right variant rather than breadth: hold verified stock of the exact orderable part the firmware was built for, and keep the migration candidate as a planned project instead of an emergency.

When only a sibling variant exists, we say so per line — with the actual difference stated (flash, PSRAM, revision, antenna) — and the decision stays with the people who own the firmware.