Have a project in mind? Let's talk.
ESP32 deep sleep power consumption is one of the most misunderstood numbers in embedded development. The datasheet promises microamps. Your multimeter shows milliamps. Both are right, and the difference between them decides whether your battery-powered sensor lasts a week or two years. This post walks through what the datasheet numbers actually mean, where the extra current goes on a dev board, which firmware settings change the figure, how to measure it properly, and how to estimate real battery life for a deployed device.
The ESP32 datasheet lists deep sleep current at roughly 10 µA with the RTC timer and RTC memory powered. The newer ESP32-S3 datasheet is more granular: about 7 µA in deep sleep with the RTC running, about 1 µA with the RTC off, roughly 240 µA in light sleep, and about 15 mA in modem sleep. Those are typical values measured at the chip's power pins on Espressif's own test fixture, with every peripheral off and GPIOs floating or held. Source Source
Those conditions are the whole story. In deep sleep the ESP32 powers off its CPUs, most of its RAM, and every digital peripheral clocked from the main bus. The only parts left running are the RTC controller, the RTC memories, and optionally the ULP coprocessor, which can keep polling a sensor while the rest of the chip is dark. The datasheet number describes that chip-level floor, not anything you can buy off the shelf. Source
A stock ESP32-S3-DevKitC-1 draws 5 to 15 mA in deep sleep, and three components on the board account for nearly all of it. The AMS1117 voltage regulator burns about 5 mA of quiescent current just to stay alive, the CP2102N USB-to-UART bridge draws 2 to 5 mA sitting idle on the 3.3V rail, and the power LED adds another 2 to 3 mA. The ESP32 chip itself is sleeping at its promised 7 µA the whole time. The board around it is not. Source
Independent board measurements tell the same story from the other direction. A DevKitC V4 measured 3.8 mA in deep sleep and a SparkFun ESP32 Thing Plus 4.1 mA, while boards designed for battery work came in far lower: a FireBeetle DFR0478 at 10 µA and an AZ-Delivery LOLIN32 at 12 µA. The spread between boards is three orders of magnitude, and it is entirely about the circuitry around the chip, not the chip. Source
Espressif's own documentation says this plainly: measuring module current through a development board is not recommended, because board circuits keep consuming power even when the chip runs the deep sleep example. If you want a number that describes the module, you measure the module on its own. Source
Before entering deep sleep, the application should stop Wi-Fi and Bluetooth with the proper deinit calls. Wireless connections do not survive deep sleep either way, but skipping the shutdown sequence leaves the sleep flow in a worse state and can cost you clean wake behavior. Source
GPIO state is the quiet current thief. Some ESP32 pins have internal pull-ups or pull-downs enabled by default, and if an external circuit drives those pins during sleep, current flows through the resistor all night. The classic case is the ESP32-WROVER, where GPIO12 has an external pull-up fighting an internal pull-down, pushing deep sleep current above the minimum. Calling rtc_gpio_isolate() on the offending pin before sleep removes the leak. Source
The clock choice matters too. An external 32 kHz crystal draws the same as the internal RTC clock, but an external 32 kHz oscillator adds 50 to 100 µA no matter which clock source the firmware selects. If your board has one populated, that alone can dwarf the chip's sleep current. Source
Flash memory is the other lever. A SPI flash chip in standby typically draws 10 to 30 µA. ESP-IDF can command the flash into deep power-down mode, which drops many flash parts below 1 µA, or cut its supply entirely for the strictest budgets, at the cost of a longer wake-up delay and some real-world sharp edges around short sleep intervals. Source
One code-level trap is worth naming because it mimics a power problem. Passing something like 9000 * 1000000 to esp_sleep_enable_timer_wakeup() with 32-bit integers overflows and makes the device wake far earlier than scheduled, which wrecks both your timing and your average current. Use a uint64_t constant. Source
An ordinary multimeter struggles here for two reasons. Deep sleep sits at a few microamps while active mode bursts into hundreds of milliamps, and most meters cannot switch ranges fast enough to follow a device cycling between the two. Worse, a meter's internal resistance drops voltage in series with the supply, which can brown out the module and corrupt the very reading you came for. Source
Espressif recommends two instruments: the Joulescope, which measures across nine orders of magnitude from amps to nanoamps with only a 25 mV drop at 1 A, and Nordic's Power Profiler Kit II, which resolves down to 100 nA. In Espressif's own measurement of a bare ESP32-S3-WROOM-1 module running the deep sleep example, the Joulescope showed 8.14 µA in deep sleep against 23.88 mA active, which is exactly the kind of figure the datasheet describes. Source
The number that actually matters for battery life is not the sleep floor but the average. A sensor that sleeps at 10 µA for 59 seconds and then spends one second awake at 100 mA averages about 1.7 mA, not 10 µA. Wake frequency and wake duration dominate the budget, which is why measuring one full sleep-wake cycle beats measuring sleep alone.
Take a common 18650 lithium cell at about 2,500 mAh. A stock dev board sleeping at 10 mA drains it in roughly ten days while doing nothing. The same cell against a 100 µA sleep current lasts over two years in sleep alone. A realistic sensor that wakes every 15 minutes, takes a reading, and transmits it lands in the 6 to 12 month range on one charge, and at a true 7 µA sleep floor the battery's own self-discharge becomes the limit instead of the circuit. Source
The transmission bursts are the expensive part. Wi-Fi transmit peaks on the ESP32-S3 run around 310 mA, so every connection is a spike hundreds of thousands of times larger than the sleep floor. Fewer, shorter, batched connections beat frequent chatty ones, and protocols designed for constrained devices help. If you are building connected sensors on MQTT, our post on ESP32 MQTT over TLS covers the transport side of that picture. Source
Three hardware changes get a dev board most of the way to its floor. First, feed regulated 3.3V straight into the board's 3.3V pin to bypass the AMS1117, which saves about 5 mA, but never connect USB at the same time or you backfeed the regulator. Second, desolder the power LED or cut its trace for another 2 to 3 mA. Third, power the board through a low-quiescent regulator such as an HT7333 breakout at about 4 µA or a Pololu D36V6F3 at 10 to 15 µA, replacing the onboard power path entirely. Source
Combined, those fixes bring a dev board into the 50 to 200 µA range, with the remaining draw coming from the USB-UART bridge still hanging on the rail. Getting below that means cutting the bridge's power or moving to a bare module on a custom board, which is the right step once firmware is proven and you are building for production volume. Source
Deep sleep is a full reboot on every wake. The digital core powers off completely, CPU context is lost, and the firmware starts over, keeping only what you stored in RTC memory. It also drops the Wi-Fi association, so every wake pays the cost of reconnecting and re-authenticating. Source
If your device must stay reachable or respond in milliseconds, light sleep keeps CPU context at roughly 240 µA on the S3, and modem sleep holds the Wi-Fi connection at around 15 mA. Always-on interactive devices like ESP32 AI voice agents live in that world, trading battery life for responsiveness. Deep sleep is for devices that can afford to disappear between events, and choosing between the two is an architecture decision, not an optimization. And once devices are deployed in the field, power bugs ship like any other bug, which is why secure OTA updates with rollback belong in the plan from day one. Source
The ESP32 chip draws about 10 µA in deep sleep with the RTC running, and the ESP32-S3 about 7 µA, measured at the chip pins on Espressif's test fixture. A stock development board draws 5 to 15 mA because its regulator, USB-UART bridge, and power LED stay on. Boards designed for battery use, like the FireBeetle, measure around 10 µA.
Almost always the board, not the chip. The AMS1117 regulator burns about 5 mA just existing, the CP2102N USB-serial chip 2 to 5 mA, and the power LED 2 to 3 mA. Firmware causes include GPIO pull-up and pull-down fights, an external 32 kHz oscillator adding 50 to 100 µA, and flash left in standby at 10 to 30 µA.
No. The digital core, including the radio, powers off, and every wake is a full reboot followed by a fresh Wi-Fi connection. If you need to hold a connection, use modem sleep at around 15 mA or light sleep at around 240 µA on the ESP32-S3 instead.
Quiescent current is what a component draws with no load, just to keep itself operating. A regulator like the AMS1117 has a quiescent current around 5 mA, which is over 500 times the ESP32-S3's deep sleep current. On a battery device, quiescent currents, not the microcontroller, usually set the sleep floor.
Use an instrument that handles fast dynamic range and low voltage drop, such as a Joulescope or a Nordic Power Profiler Kit II, and measure a bare module rather than a dev board. Ordinary multimeters switch ranges too slowly and drop enough voltage to brown out the chip. Measure full sleep-wake cycles, since the average over a cycle determines battery life.
A 2,500 mAh 18650 cell lasts about ten days against a stock dev board sleeping at 10 mA, over two years against 100 µA, and is limited by self-discharge rather than the circuit at 7 µA. Real deployments are set by wake frequency: a sensor waking every 15 minutes to measure and transmit typically runs 6 to 12 months per charge.
Ready to take the first step towards unlocking opportunities, realizing goals, and embracing innovation? We're here and eager to connect.