Blog
ESP32 EEPROM: Emulated, NVS, Preferences
Does esp32 have eeprom, how to clear it, and why NVS beats it — persistence questions without a 200-page datasheet.
Does ESP32 Have EEPROM?
No physical EEPROM — the ESP32 emulates it in flash. The Arduino EEPROM library gives you 4096 bytes that survive resets but wear flash if hammered; Preferences (NVS) is the recommended path for new projects — more space, strings, wear leveling. The EEPROM library exists for porting old sketches, and it works, mostly.
EEPROM vs NVS vs Preferences — what is the difference?
Three layers, one storage medium. EEPROM is the Arduino-legacy byte-addressed API. NVS is the native ESP-IDF key-value store, wear-leveled and crash-resilient. Preferences is a thin Arduino wrapper over NVS. Pick by need: old code → EEPROM; new code → Preferences. Same flash, different writes.
How to Clear EEPROM ESP32?
Fill the range with zeros and commit: loop EEPROM.write(i, 0) then EEPROM.commit() — or overwrite only the addresses you care about. For everything, esptool.py erase_flash wipes EEPROM, NVS, and the filesystem in one shot — the same answer to how to wipe esp32 completely. Details in the flashing FAQ.
How to Save Array Data to NVS Flash ESP32?
Preferences.putBytes(): prefs.begin("cal", false), prefs.putBytes("calib", myArray, sizeof(myArray)), then prefs.getBytes("calib", myArray, sizeof(myArray)) on boot. Structs work identically with &myStruct and sizeof(myStruct). NVS is the right home for calibration tables and device IDs. More snippets in our examples.
How to Store Data in ESP32?
Key-value pairs → Preferences/NVS. Named files → LittleFS, the maintained choice; what is spiffs esp32 — a flash filesystem from 2015 — still ships with the core, but LittleFS is where new work goes. Big data and media → SD card over SPI.
How to Increase Storage Space on ESP32?
Resize partitions, add a filesystem partition, or go external. NVS defaults to 24 KB but a custom partition table can grow it; LittleFS sizes the same way. Past a few megabytes, use an SD card — gigabytes for a dollar. The flash chip is fixed; partitions are your levers.
How many writes can NVS survive?
Millions of small writes — NVS wear-levels across its partition instead of grinding one sector; raw endurance is roughly 10k–100k erase cycles per cell. What kills it is a write loop. I logged to Preferences every iteration of an S3 dev board once; three months later the calibration table read garbage. A few hundred bytes a few times per minute is fine for years.
Why does my saved value read back as 255?
Either it was never committed, or it lives at a different address. Forgetting EEPROM.commit() is the classic bug — uncommitted writes vanish on reset. First boot after erase_flash also reads 255, because erased flash is all 0xFF. ATmega sketches port poorly — a byte offset that “works on Uno” is usually the story.
Can EEPROM store floats and structs?
Yes — EEPROM.put() stores any type, floats and structs, and EEPROM.get() reads it back. Preferences goes further: strings, blobs, and numbers. EEPROM is byte-addressed, so you track sizes yourself; Preferences does it for you.
Does EEPROM work on ESP32-S3 and C3?
Yes, every current ESP32 family emulates EEPROM in flash the same way, so sketches port across models mostly seamlessly. The gotchas are model-independent: commit before restart, mind the 4096-byte ceiling, expect no endurance.
R/W a Real EEPROM — In Your Browser
The write-verify loop that ESP32 Preferences/NVS does for you internally, visible by hand on an external chip:
- I2C EEPROM R/W test at 0x50 — write, then read back what you wrote:
============================
I2C EEPROM R/W Test (0x50)
============================
Writing test data...
Write reg[0] = 42
Read reg[0] = 42That moment of Write = Read is the whole contract of nonvolatile memory. When NVS/Preferences misbehave on real hardware, this is the layer you are debugging underneath it — and the scanner is how you confirm the chip even answered at 0x50.