The Verification Venue · a thing everyone gets half-right
Deleted Is Only a Word for Forgotten
You emptied the trash. The file is gone from view, but on a hard drive, a USB stick, or an SD card, the bytes are still there, whole, waiting to be overwritten. That is the entire reason recovery software exists. The one place that isn't true anymore: an internal SSD with TRIM, where the drive quietly erases itself within seconds.
The answer
Emptying the trash removes the file's directory entry and marks its blocks free. It writes over zero of the file's data bytes; they persist until something else reuses that space.
So: recoverable until overwritten. On an HDD, USB SSD, or SD card that can be weeks or indefinitely. On an internal SSD with TRIM, the controller garbage-collects the freed NAND and post-delete reads return zeros or garbage (RZAT/DRAT): usually gone within seconds to minutes. Caveat that makes or breaks this: TRIM is not universal. It needs operating-system + filesystem + interface support, so USB-attached SSDs, SD cards, and many RAID arrays lack it and behave like an HDD. Encrypted volumes flip the whole model to crypto-erase.
Below is a live recovery-odds instrument. Pick the drive your file was on, set how much the drive gets written afterward, and watch the probability that your file is still recoverable decay over time. Two opposite crowds meet on this one curve: the people trying to recover a file, and the people trying to destroy one. The curve is right, and different, for both.
Bytes of the file erased by "empty trash"
0 of 4.00 GB
only the directory entry (~168 bytes) is rewritten
Recovery window (odds fall below 1%)
–
time until the file is effectively gone
Still recoverable after 1 day
–
at the read cursor below
Size sets how many bytes were freed, never how many were erased. That count stays 0.
How fast the free space churns. More writing = your freed blocks get reused sooner.
More free space = new writes are unlikely to land on your file's old blocks.
On a TRIM'd SSD, how long before the controller physically erases the freed NAND. Seconds to minutes.
Drag along the time axis to read the recoverable probability at any moment.
The reversal cuts both ways
The folk advice on this topic is split into two tribes, and the SSD/TRIM shift makes each one wrong in the opposite direction:
"How do I recover it?": right on an HDD, USB stick, or SD card, where the bytes sit untouched for a long time. But usually too late on a TRIM'd internal SSD: by the time you notice, garbage collection has run and the drive returns zeros. The recovery SaaS pages that sell you software rarely mention this cliff, because it's the case their product can't win.
"How do I delete it so nobody can recover it?": the instinct to "shred" or secure-wipe a single file is wrong on an SSD. Because of wear-leveling, the controller constantly relocates data to spread writes evenly, so the physical NAND pages holding your old data are addresses the operating system cannot reach. A per-file overwrite can't touch them. Wei et al. (USENIX FAST 2011) pulled raw data off SSD chips after exactly these "secure" single-file wipes. Only a full-drive operation works: an ATA Secure Erase / the drive's sanitize command, or cryptographic erase (throw away the encryption key so all ciphertext becomes noise). Per-file shred is HDD-era advice.
The third layer: TRIM is not a law of nature
The whole "SSD = gone in seconds" claim is conditional. TRIM only fires when the operating system, the filesystem, and the interface all support and pass it through. Break any link and the SSD reverts to HDD behaviour, recoverable:
| medium / path | TRIM? | behaves like | recovery window | to really destroy a file |
|---|---|---|---|---|
| Internal NVMe/SATA SSD, modern OS + FS | yes | SSD cliff | seconds–minutes | ATA Secure Erase / sanitize (whole drive) |
| SSD in a USB / Thunderbolt enclosure | often no* | HDD | days–indefinite | whole-drive secure erase |
| SD card / microSD / cheap flash | no | HDD | days–indefinite | whole-drive erase (or physical destruction) |
| SSD behind a hardware RAID controller | often no | HDD | days–indefinite | whole-drive secure erase |
| Spinning hard drive (HDD) | n/a | HDD | days–indefinite | overwrite the file, or whole-drive wipe / degauss |
| Encrypted volume (BitLocker / FileVault / SED) | n/a | crypto | instant on key destroy | destroy the key = crypto-erase (all media) |
*Many modern USB bridges do pass TRIM (UASP); older or cheaper ones don't. If you can't confirm your enclosure supports it, assume it behaves like an HDD.
Encryption flips the model entirely. On an encrypted drive nothing on the platter is ever plaintext, so you never need to erase the data: you erase the key. That is why "crypto-erase" is instant and total, and why a self-encrypting drive can be wiped in a second regardless of whether it's SSD or HDD.
The check: every number recomputed in front of you
Two things are shown. (1) The mechanism is definitional: emptying the trash is an unlink + free-list update. Bytes of the file it overwrites = 0, for any file size: that's not a model, it's what the operation does. (2) The recovery curve is an explicit named model, recomputed here with your slider values:
HDD / no-TRIM model: new writes reuse free space at random, so a freed block survives with probability P(t) = exp(−W·t / F), an occupancy model. Half-life t½ = F·ln2 / W. Real filesystems cluster allocations rather than scatter them, so actual persistence is usually longer than this; the model errs toward the recovery crowd, not against them. SSD+TRIM model: P(t) = exp(−t / τ), a fast decay as garbage collection erases the NAND; once it completes, reads return zeros (RZAT) or a fixed pattern (DRAT) and recovery through the drive is 0. The cliff shape is certain; the exact τ (seconds–minutes) is the one free knob, and it's yours to set.
Free choices & uncertainties, named: uniform-random reuse (real FS clusters → longer); recoverability defined as per-block survival / expected fraction of the file intact; τ_gc is device- and workload-dependent; DRAT vs RZAT is a per-drive IDENTIFY flag, so "returns zeros" vs "returns deterministic garbage" varies; all of it is defeated or irrelevant under encryption (crypto-erase).
The same arithmetic runs offline: node research/does-emptying-the-trash-delete-files/verify-does-emptying-the-trash-delete-files.mjs (reproduces every number two independent ways; exits 0 on all-pass).
What's exactly true, what's modelled, and what I could not pin down
Exactly / definitionally true. Emptying the trash deletes the directory entry and frees the blocks; it does not overwrite file data. This is why undelete and file-carving tools work at all, and it's independent of OS and filesystem. Wear-leveling does relocate SSD blocks beyond OS addressing, which is why a per-file overwrite cannot guarantee erasure on an SSD (Wei et al., FAST 2011). Post-TRIM reads returning deterministic zeros (RZAT) or a deterministic pattern (DRAT) is defined in the ATA command set (IDENTIFY DEVICE word 69: bit 5 = RZAT, bit 14 = DRAT; word 169 bit 0 = TRIM supported).
Modelled, not measured. The recovery-odds curve is an illustrative probabilistic model, not a measurement of your specific drive. The HDD half-life comes from a uniform-random-reuse assumption; real allocators cluster writes, so files often survive far longer (partial overwrites also still allow partial recovery, which the curve doesn't credit). The SSD τ is a stand-in for garbage-collection timing that varies by controller, fill level, and idle time; the honest claim is "post-TRIM reads typically return zeros/garbage and recovery becomes impractical within seconds to minutes," not "physically zeroed the instant you hit delete." Physical NAND erasure happens at garbage collection, which can lag the TRIM command.
Security advice, stated carefully. Do not read "recoverable" as "recoverable by you, easily"; professional recovery on a heavily-written HDD is not guaranteed either. And do not read the SSD cliff as permission to skip proper sanitization: to reliably destroy data use a whole-drive ATA Secure Erase / sanitize, or cryptographic erase; per-file "shred" utilities are unreliable on SSDs and flash. This is a mechanism explainer, not a forensic or compliance guarantee (see NIST SP 800-88 for the standard).