The fastboot boot command loads a kernel, boot image, or recovery image directly into RAM and runs it without touching the device's storage partitions. When the device reboots or powers off, it returns to whatever was written in flash before. This makes it an essential tool for safely testing a custom recovery or patched boot image before you commit to a permanent flash.
fastboot flash boot image.img permanently writes the image to the boot partition on internal storage. Once flashed, that image boots every time until something else overwrites it. If the image is incompatible with your device, does not initialize critical partitions, or has an error in its ramdisk, you may be left with a device that does not complete boot. Recovery from that state usually requires another fastboot session or a working backup.
fastboot boot image.img skips storage entirely. The bootloader loads the image into memory and hands control to it exactly as if it had been read from flash, but nothing is written. When you power off or when the session ends, the device starts from the image that was already in the boot partition. This one-shot behavior makes the command invaluable for two scenarios: trying out a TWRP build to see if it detects your partitions correctly before you overwrite your stock recovery, and testing a Magisk-patched boot.img to verify root is working before you permanently replace the stock boot.
Not all devices support fastboot boot. The command requires the bootloader to implement the boot command in its fastboot protocol stack. Google Pixel devices (all generations) support it reliably. Many Motorola, OnePlus, and ASUS devices do as well. Some MediaTek devices and several Qualcomm devices from brands that customize their bootloaders may return an error like FAILED (remote: 'unknown command') or FAILED (remote: 'not supported'). If your device returns one of those errors, you have no option but to flash the image if you want to test it.
You need an unlocked bootloader, Android Platform Tools installed and in your system PATH (or accessible via a direct path), the image file you want to test, and the device in fastboot mode. The device does not need to have ADB active; the entire operation runs through the fastboot protocol. USB Debugging being on or off makes no difference once you are in fastboot mode. Ensure you have the correct image for your exact device variant. A boot image built for a different hardware revision or even a different RAM configuration of the same phone model may boot to a kernel panic or a blank screen.
C:\platform-tools\twrp.img on Windows or ~/platform-tools/twrp.img on macOS and Linux.adb reboot bootloader.fastboot devices to confirm the device is recognized. You should see the serial number with the status fastboot.fastboot boot twrp.imgC:\platform-tools\fastboot.exe boot C:\platform-tools\twrp.imgThe Magisk installation workflow for devices that cannot use TWRP involves copying the stock boot.img to your phone, patching it with the Magisk app, copying the patched file back to the PC, and flashing it. Before permanently flashing, you can test the patched image with fastboot boot to confirm that root works and the system boots cleanly:
fastboot boot magisk_patched_abc123.imgThe device will boot into Android with the Magisk-patched kernel loaded from RAM. Open the Magisk app; if it shows root access as active, the patch is compatible with your device. Open a terminal emulator and run su to verify that root grants are working. If everything looks good, you can then proceed to permanently flash the patched image with fastboot flash boot magisk_patched_abc123.img. If something is wrong, simply reboot; the stock boot partition is untouched and the device returns to its original state.
Devices that use an A/B partition layout (also called seamless updates) maintain two copies of the boot partition, labeled slot A and slot B. The fastboot boot command on A/B devices still works, but be aware that the temporary boot operates independently of the current active slot. Some A/B bootloader implementations behave slightly differently: the temporary boot image may or may not have access to the same userdata depending on the encryption state and slot context. For most testing purposes this does not matter, but if you are testing a recovery image that needs to mount /data, verify that the recovery can access userdata before concluding the test was fully successful.
Secure Boot on Android devices is enforced by the bootloader's verified boot implementation. An unlocked bootloader disables verified boot enforcement, which is why fastboot boot with an unsigned or custom image works at all. The device will show an orange or red state warning screen on boot to indicate that verified boot is disabled. This is expected behavior and does not indicate a problem with the image itself.
No. The entire point of fastboot boot is that nothing is written to storage. When the device shuts down or reboots for any reason, it boots from whatever image was already in the flash partition. Your existing boot environment is completely untouched throughout the test session.
It means your bootloader does not implement the fastboot boot command. This is a firmware limitation, not a software problem. There is no workaround short of flashing the image directly. Some devices have community-modified bootloaders that add this support, but those require flashing a custom bootloader, which carries its own risks.
The image must fit in the download buffer that the bootloader allocates, which varies by device. Most modern devices allocate at least 64 MB for the download buffer, and typical boot images are well under that. Recovery images can be larger; TWRP builds are usually between 40 MB and 120 MB. If the image exceeds the buffer, fastboot will report a "download failure" or "buffer too small" error. In that case, you have no option except to flash the image rather than RAM-boot it.
No. The stock recovery partition is not read or written during a fastboot boot session. After rebooting, pressing the recovery key combination will still load whatever recovery was written to the recovery partition (on A-only devices) or the current slot's recovery (on A/B devices). Using fastboot boot to test TWRP is specifically safer than flashing TWRP because the stock recovery remains available if anything goes wrong.