Fastboot

Fastboot Erase and Format: Wiping Partitions Safely Before Reflashing

Published: July 6, 2026 • Applies to: Devices in Fastboot mode with an unlocked bootloader

Flashing guides frequently include a "wipe cache and data" step without explaining what the underlying commands actually do or why one partition needs a full filesystem format while another only needs its blocks zeroed. Getting this wrong on the wrong partition is one of the more common ways a routine ROM flash turns into a device stuck in a boot loop.

Erase vs. Format: The Actual Difference

fastboot erase <partition> zeroes out the raw blocks of a partition without writing a new filesystem structure to it. The next time Android boots, it detects the partition is unformatted and creates a fresh filesystem on first mount.

fastboot format <partition> does both steps at once: it erases the blocks and immediately writes a new, empty filesystem (typically ext4 or f2fs depending on the partition and device) so the partition is mountable right away, without waiting for Android to do it on first boot.

For most user-triggered wipes, format is the safer choice because it guarantees a consistent filesystem state immediately. erase is more commonly used inside flashing scripts where the ROM installer itself creates the filesystem afterward, making a pre-formatted partition redundant work.

Common Commands and What They Wipe

fastboot erase cache
fastboot format userdata
fastboot format cache
fastboot erase metadata

cache — holds temporary app and OTA update data. Safe to wipe at any time; Android rebuilds it automatically. Many modern devices no longer ship a separate cache partition at all, in which case these commands return "partition does not exist," which is expected and not an error to worry about.
userdata — contains all apps, accounts, photos, and settings. Wiping this is equivalent to a factory reset and cannot be undone without a backup. Always confirm this is actually the step you intend before running it against a device with data you have not backed up.
metadata — stores File-Based Encryption policy state on newer Android versions. Wiping it is sometimes required when switching between ROMs with incompatible encryption schemes, but doing so on a device where it is not needed can leave userdata unreadable until a fresh format.

When a Wipe Is Actually Required

Flashing a new ROM build from the same source and same Android version as the currently installed one usually does not require wiping userdata — a "dirty flash" over the existing installation works in most cases. A wipe becomes necessary when:

Switching between ROMs from different developers or forks, since app data and system settings from one ROM's framework are frequently incompatible with another's.
Moving between major Android version jumps (for example Android 13 to Android 15), where the userdata schema itself changes.
Recovering from a boot loop where the cause is unknown — a full wipe rules out corrupted userdata as the culprit before investigating a firmware-level issue.

Partitions You Should Not Touch Manually

Never run fastboot erase or fastboot format against boot, system, vendor, persist, or any partition holding calibration data (Wi-Fi MAC address, IMEI-related data, DRM keys) unless you have a verified backup and know exactly what you are restoring. These are not filesystem partitions in the same sense as userdata — several of them hold raw binary images that a generic erase or format command will corrupt rather than reset cleanly, and some (persist, calibration partitions) cannot be regenerated from a stock firmware package at all.

Erase Commands Require an Unlocked Bootloader

All of the erase and format commands above fail with a permission error on a locked bootloader, the same restriction that applies to flashing. If fastboot format userdata returns something like "FAILED (remote: 'Erase is not allowed'"), the bootloader is locked and the unlock step needs to happen first — there is no wipe workaround for a locked device.

Verifying After a Wipe

After wiping userdata and rebooting, the device should boot to the initial Android setup wizard rather than a lock screen prompting for a PIN or password. If it instead boots directly past setup to a home screen with old apps still present, the wipe did not actually complete, most often because the device was still communicating with a stale Fastboot session; reboot into Fastboot fresh and repeat the command.