WHERE DO DELETED FILES GO? THE TRUTH ABOUT DELETE YOU NEVER KNEW

Let's start simply. Suppose we have a file: photo.jpg. The operating system needs to know where this file sits on the disk. For that, the file system keeps records about every file:

When you delete the file, in many systems the first thing that happens is not erasing all the zeros and ones from storage. Instead, the operating system declares: "this file is no longer needed, and the space it occupied can be reused."

The data may still be sitting on the media — the file system just no longer recognizes it as a usable file. This single difference is the foundation of most file recovery tools. NIST's current media sanitization guide also stresses that "deleting" is not the same as a process that makes data practically inaccessible — residual data may still be recoverable.

Suppose your 100 MB file was deleted. If the OS marks that 100 MB as free, a new file may not have been written over it yet. As long as nothing else has overwritten that space, recovery tools may still find parts of the old data.

This is where it gets interesting. With an old HDD, the story is relatively straightforward: data lives on magnetic platters, and the OS can remove a file from the file system's view while its content remains on the media until overwritten.

But on an SSD, things are more complex. SSDs use flash memory, and their controller constantly manages memory cells with Wear Leveling and Garbage Collection. Even the concept of "this file lives in these cells" isn't as simple as on an HDD.

When a file is deleted from an SSD, the OS can notify the drive via a command called TRIM that certain blocks no longer contain needed data. The SSD can then prepare that space for reuse in the background.

Now the strange part begins. Suppose you delete vacation.jpg from your phone or computer. You may have deleted the original file — but did you really delete all copies of it? Maybe not. Versions of it may survive elsewhere:

Open a folder full of photos. Before you open any image, Windows or another app shows you a preview. That preview may be stored as separate data. So you can delete the original photo while its thumbnail quietly survives. This doesn't mean you can always reconstruct the full image from a thumbnail — but it shows a file can leave more traces than what you see in the folder.

Imagine you deleted a file from your computer — but before that, you had opened it in a browser. Browsers store data in caches to increase speed. Deleting a file from disk doesn't mean every trace of it vanished from every piece of software on the system.

For developers this gets even more interesting. Suppose an app stores this record in a database:

Now you delete the record: DELETE FROM users WHERE id = 42;. Logically, the record no longer exists. But the database storage system may also keep:

Suppose the file is deleted — completely gone from the SSD. But your system runs a nightly backup. The file exists in last night's backup version. Deleting from the device is not the same as deleting from every stored copy. This is why cloud services and enterprise systems have separate retention, versioning, and backup policies.

When you store a file in a cloud service, it doesn't just live on your laptop. It may exist in the main storage, in replicas, in versions, and in backups. So when you press Delete, a new question arises: deleted from where?

This is one of the key reasons permanent deletion in distributed systems is genuinely hard.

A common belief: "I formatted the disk, so all data is destroyed." But the word Format alone isn't enough. The format type, media type, and method all matter. In many scenarios, formatting simply rebuilds the file system structure — it doesn't necessarily destroy all physical data immediately. This is why NIST distinguishes between Clear, Purge, and Destroy, treating secure sanitization as something entirely separate from an ordinary format.

An old mistake: assuming that filling the entire SSD with zeros multiple times is the most secure method. But because of Wear Leveling, Overprovisioning, Garbage Collection, and the Flash Translation Layer, an SSD doesn't behave like a simple HDD. NIST SP 800-88 Rev. 2 explicitly states that traditional overwriting methods are not necessarily appropriate for SSDs with overprovisioning — proper sanitization mechanisms should be used instead.

For sensitive data, the goal isn't just hiding the file from Explorer. The goal is making access practically impossible for the threat level in question. NIST's current Media Sanitization guide defines three main concepts:

Which method is appropriate depends on the media type and the sensitivity of the information.

Here's one of the most fascinating ideas. Suppose all your data was encrypted from the start. Even if the encrypted bits still exist on the media, they're useless without the right key. Now, if you securely destroy the encryption key, the data becomes cryptographically inaccessible. This technique is called Cryptographic Erase, and NIST SP 800-88 Rev. 2 covers it as one of the important sanitization methods.

In some modern systems, encryption is built deeply into the device. Apple, for example, explains that in its Data Protection architecture, destroying the appropriate keys can render files cryptographically inaccessible.

A smartphone is not just a simple flash drive. Modern devices combine flash storage, a file system, encryption, secure hardware, and cloud backup. So a Factory Reset on a modern phone can be very different from deleting a file on an old computer. On devices with proper encryption, destroying encryption keys can be a core part of securing the data.

No — and this part matters a lot. Sometimes a file is recoverable. Sometimes only part of it. Sometimes only its name or metadata survives. Sometimes the SSD's TRIM and internal operations have made recovery extremely difficult. And sometimes, due to overwriting, corruption, encryption, or proper sanitization, the data is practically gone forever.

Both beliefs are mistakes. The truth lives in between, and depends on the storage stack.

Let's build a realistic example. You have a photo: IMG_2037.jpg. This photo may exist in the system like this:

Now you delete the original. The original is gone — but the thumbnail, backup, cloud version, and metadata may all still exist. So the real question is no longer "did I delete the file?" but rather: "what happened to every path this data could have lived along?"

There's a subtle point here. Sometimes what remains after deletion isn't the complete file — just information about it: the filename, timestamps, file size, location, thumbnail, or other metadata. A "trace of data" is not the same as "the data itself." This distinction matters enormously in forensic investigations.

Now let's step outside the computer. Suppose you post a photo online and delete it a few hours later. Is the story over? Not necessarily. Copies may exist in caches, CDNs, search engine indexes, screenshots, other users' downloads, and archives. Even if the origin server deleted the file, someone else may have already downloaded it — and no technique on the origin server can destroy a copy saved on someone else's computer.

Here, data deletion is no longer just a technical matter — it enters the territory of ownership, privacy, and information spread.

In the digital world, deletion can mean several very different things:

These are not the same thing — not even close.

For everyday use, you don't need heavy sanitization methods every time you remove a photo. But when genuinely sensitive information is involved, things change. For example, when disposing of or handing over a system:

Perhaps the most fascinating part of this story: when we press Delete, we imagine a sudden event — file, delete, nothing. But what may actually happen looks more like this:

Deleting data is sometimes less like destroying information and more like erasing the map to it.

There's no one-word answer. On an HDD, proper overwriting can make recovery extremely difficult. On an SSD, you must consider the media's behavior, its controller, and its sanitization capabilities. On an encrypted device, destroying keys can make data cryptographically inaccessible. And in a cloud service, backups, replication, and retention policies all come into play. That's exactly why modern standards talk about Media Sanitization instead of just "delete the file" — a process that makes data access practically impossible relative to the expected level of effort.

Next time you delete a file, it might be worth pausing for a second: Where was the file? What did the OS actually delete? What did the disk keep? Was there a backup? Did the cloud have a copy? Did another app build a cache? And most importantly — did the data even need to remain recoverable in the first place?

The world of storage isn't just about keeping information. The harder part is knowing how to truly take information we no longer want out of reach.