When I delete a photo from my iPhone, is it actually gone?

Not for at least 30 days, and possibly much longer depending on what else has touched it. iOS moves deleted photos into the Recently Deleted album, which retains them for 30 days before automatic purge - you can also empty it manually. If iCloud Photos is on (which is the default for most users), the deletion has to propagate to every other device signed into the same Apple ID and to Apple's servers, which can take hours and which leaves a copy in the iCloud Recently Deleted bin for the same 30 days. Beyond that, the photo may live on in derived data: thumbnail caches that the OS uses for the Photos grid, the Memories machine-learning index, the People-and-Pets recognition cache, the search index, and any third-party app (Messages, WhatsApp, Telegram) that received a copy of the photo and stored it in its own cache. Each of those is a separate cleanup. The photo file itself is also still physically on the SSD until the controller decides to reclaim the block, which can be weeks.

Does Google Photos really keep deleted photos for 60 days?

Yes. Google Photos moves deleted items to Trash, which holds them for 60 days before permanent deletion - longer than Apple's 30. If the photo was in a shared album, the cached copy on other people's devices is governed by their device caches, not yours, and Google does not actively yank it back. If you backed up the photo to Google Photos and then deleted the local copy from the phone but left the cloud copy, the photo is still in the cloud. If you deleted from the cloud but the phone has not synced, the local copy is still there. The cleanest way to know the photo is gone everywhere is to empty Trash explicitly, then check the phone's local Recently Deleted, then disconnect any third-party apps you granted Photos access to (those copies are not Google's to delete).

Why does deleting a file on an SSD not actually erase the bytes?

Because of how SSDs are physically built. SSDs cannot overwrite a page in place the way a hard drive can - to write new data to a NAND cell, the entire block (typically 128 to 256 pages) has to be erased first. That makes in-place overwrite extremely slow, so SSDs instead write new versions of data to fresh blocks and mark the old blocks as 'invalid'. A garbage-collection routine on the drive consolidates and erases invalid blocks in the background, when it gets around to it. Combined with wear-levelling (which spreads writes across the drive to even out cell wear) and over-provisioning (the 7-20% of capacity reserved outside the user-addressable area), this means a 'deleted' file's bytes can sit in NAND cells for weeks or months, invisible to the operating system but recoverable with forensic tools that read the drive directly.

So what does 'secure erase' mean on an SSD if you can't just overwrite the bytes?

On modern SSDs it means a cryptographic erase. Almost every SSD shipped in the last decade encrypts everything written to it with an internal Data Encryption Key (DEK), even if you have not turned on any user-facing encryption. The DEK lives in a small protected area of the drive. A secure erase command (ATA Secure Erase, NVMe Sanitize, or the manufacturer's equivalent) tells the drive to throw away the DEK and generate a new one. After that, every encrypted block on the drive is mathematically unreadable, regardless of which physical NAND cells the bytes are still sitting in. This is why the operation completes in seconds on an SSD - it is not overwriting anything. The same trick is what makes 'Erase All Content and Settings' on an iPhone or 'Factory Reset' on a recent Android phone effectively instant: the OS throws away the key, and the encrypted user data on the flash becomes noise.

Is the 'shred' command or DBAN still useful on an SSD?

Mostly no, and it can be counterproductive. Tools like shred, DBAN, and multi-pass overwrite utilities were designed for spinning hard drives, where overwriting a sector physically replaces the magnetic state on the platter. On an SSD, those tools write the overwrite pattern to wherever the controller decides to put it - typically a fresh block - not to the original block. The original block sits in NAND, still containing the data you were trying to destroy, until garbage collection gets to it. You also burn through a chunk of the drive's write-endurance budget for no security gain. The correct tool on an SSD is the drive's built-in secure-erase command (issued via the manufacturer's utility, hdparm with the right flags, or the OS's drive-erase tool) or whole-disk encryption from day one, which makes 'delete the key' a complete answer.

What happens to a deleted email - in Gmail, Outlook, Apple Mail?

Same general pattern as photos, with longer tails. Gmail moves deleted messages to Trash for 30 days, then purges - except in Workspace accounts where an admin can configure retention to keep deleted mail searchable through Vault for years. Outlook.com and Microsoft 365 move messages to Deleted Items, then to Recoverable Items, with a default 14-day window on the second stage that admins can extend to 30. iCloud Mail keeps trashed messages for 30 days. None of these timers cover the copy on the other side of the conversation - the person you emailed still has the message in their inbox and there is nothing you can do about it. They also do not cover any IMAP client that synced the message to a local laptop, any backup service that picked it up, or any forensic recovery that could pull it from an unencrypted backup of the device that held it.

Is there anything I can do to delete a file properly without thinking about all this?

Yes. Turn on full-disk encryption from day one on every device you own (FileVault on Mac, BitLocker on Windows, default on iPhone and any recent Android). Once a device is encrypted at rest, 'delete' becomes much closer to its intuitive meaning, because every leftover byte in flash is encrypted noise to anyone without the key. When you decommission a device, run the manufacturer's secure-erase or the OS's reset-with-erase, which throws away the key. For cloud accounts, learn where the recycle bin is for each service you use, empty it explicitly when you mean to, and remember that the other person in any conversation has their own copy that you cannot delete. That handles the 95% case without needing forensic tools or special habits.

What 'delete' really does - on your phone, in the cloud, on an SSD

Tap delete and the file disappears from the screen. The photo is gone from the grid, the email is gone from the inbox, the document is gone from the folder, the message is gone from the thread. The intuitive story is that the bytes have been removed from the device and stopped existing. The actual story is that almost none of that is what happened.

What happened depends entirely on where the file lived. On a phone, delete almost always means "move to a 30-day bin" and "leave a thumbnail behind in three different caches". In iCloud or Google Photos, it means "queue for cloud propagation, sit in a recycle folder for 30 to 60 days, possibly remain in a shared-album cache on someone else's device, and stay in a machine-learning index that is not visibly tied to the photo anymore". On the SSD inside the device, it means "tell the operating system the blocks are free to reuse" - and the physical bytes can sit there, fully readable, for weeks or months because of how SSDs are built.

This piece walks through what delete actually does at each layer - the operating system, the cloud sync, the SSD itself - and what "secure erase" means in 2026, which is something completely different from what it meant in the era of spinning disks. The goal is to give you a working model that matches reality, so the next time you delete something that matters, you know what you actually need to do.

Layer one: the application's bin

The first layer of "deleted" is the one most people interact with consciously. Almost every consumer application that handles personal data implements a soft-delete pattern: the visible UI removes the item, but the bytes are moved to a holding area for some window of time so the user can recover from a mistake. This is sensible product design - support tickets about "I deleted my wedding photos" outnumber support tickets about "my deleted file is still recoverable" by several orders of magnitude - and the windows are long enough to be a real privacy consideration if you have not thought about them.

The map for the apps most people use:

iOS Photos: Recently Deleted album, 30 days, automatic purge after that. Can be emptied manually. Items remain searchable while in the album, and they sync to every other device on the same Apple ID, including the cloud copy.
Google Photos: Trash, 60 days, automatic purge. The longest window of the major photo services. If you backed up the item to the cloud before deleting, deleting from the phone does not delete from the cloud unless the setting "Delete from everywhere" is selected.
Files app on iOS, Finder on macOS: Recently Deleted / Trash, 30 days on iCloud Drive, no automatic purge for local Trash on macOS until the user empties it (though "Remove items from the Trash after 30 days" can be enabled in Finder preferences).
Gmail, Outlook.com, iCloud Mail: 30 days in the consumer products. Microsoft 365 corporate accounts can be set to retain "Recoverable Items" for years under admin control.
Notes (Apple) and Keep (Google): Recently Deleted, 30 days.
Messages / WhatsApp / Signal: deletion behavior varies. "Delete for me" removes the message from your device only. "Delete for everyone" sends a tombstone instruction to the other devices, which may or may not honor it depending on the version and whether the message was already read or screenshotted.

The pattern to learn is: when you press delete in a consumer app, you are almost certainly starting a 30-to-60-day countdown, not removing the file immediately. If you mean immediately, you need to open the bin and empty it explicitly. Even then, you have only finished layer one.

Layer two: the cloud sync and its caches

Most of the apps above sync to a cloud service that you may or may not have thought of as a separate place. iCloud Photos is not just a backup of the Photos app on the phone; it is a server-side photo library that the phone, the iPad, the Mac, and any iCloud.com session all view through different windows. Deleting on one device propagates a delete to all the others, but the propagation is not instant, and the cloud has its own bin separate from the device's bin.

The practical consequences:

A photo deleted on your phone enters the phone's Recently Deleted and the cloud's Recently Deleted at the same time, on separate 30-day timers. Emptying the phone's bin does not empty the cloud's bin.
If you shared an album, a photo, or a link, the recipient's device has its own cached copy that is not under your control. Apple's Shared Albums and Google's shared albums both work this way. Deleting the original removes it from the album view, but downloaded copies stay downloaded.
If a third-party app (a photo-editor, a print service, a backup utility) was granted Photos access at some point, its own cache may hold a copy. Granting Photos access in 2026 is usually scoped to specific items or to "limited access", but older grants from before that UI shift may have given the app full library read - and the deleted photo could still be in its cache.
The machine-learning indices - the People and Pets album, the Memories slideshows, the on-device search index that lets you find photos by content ("dog", "beach", "receipts") - are built from the photos but stored separately. Deleting a photo does remove it from those indices over time, but the rebuild is gradual and the inferred metadata (this person appears in your library, this trip happened) can persist as a fact about your library after the source photo is gone.

Email has the same structure with different details: the messages in the cloud, the copies on other devices that sync via IMAP, the backup the desktop client may have made, the forwarded copies in someone else's inbox, the conversations indexed by spam filters and analytics pipelines. The headline service deletes when you tell it to. The shape around it does not always.

Layer three: the file system on the device

Below the application's bin sits the file system, which is what the operating system uses to track files on the storage device. Most modern file systems - APFS on Apple devices, NTFS on Windows, ext4 on Linux, F2FS on many Android phones - do not zero out a file when it is deleted. They mark the file system's metadata entry as free (the equivalent of crossing the name off the table of contents) and leave the underlying data blocks alone until something needs to write to them.

On a spinning hard drive, this is the classic "the bytes are still there until they are overwritten" model that data-recovery tools have exploited for decades. Run a recovery tool, scan the unallocated space, find file signatures (a JPEG starts with FF D8 FF, a PDF starts with 25 50 44 46, a Word document has a recognizable OLE/OOXML header), and reconstruct files that the file system has forgotten about. This is the entire premise of products like Recuva, PhotoRec, and the forensic suites used by law enforcement.

On modern devices, two things have changed the picture. First, full-disk encryption is now the default on almost every consumer device that ships in 2026 - iPhones since 2014, Macs with FileVault enabled by default in modern macOS, Windows 11 with BitLocker on most new machines, Android with file-based encryption since Android 10. When the disk is encrypted, the bytes sitting in unallocated space are encrypted noise to anyone without the key, which means recovery from a powered-off and locked device requires breaking the encryption, not just running PhotoRec. Second, the storage device is almost always an SSD, which behaves very differently from a spinning disk under the file system.

Layer four: what the SSD actually does

This is the layer most people have never had a reason to think about, and it is the one with the biggest mismatch between the intuitive model and the reality.

A spinning hard drive is, physically, a stack of metal platters with a head that reads and writes magnetic patterns on them. Writing a new value to a sector means moving the head over the sector and changing the magnetic pattern in place. Deletion is symmetric: write zeros to the sector, the old pattern is gone. Multi-pass overwrite tools (the famous Gutmann 35-pass scheme, DBAN's defaults, the US Department of Defense 5220.22-M three-pass pattern) were designed around the small possibility of magnetic residue being recoverable with electron microscopy. On modern drives, even a single pass of zeros is enough.

An SSD is not built like that. The storage cells are NAND flash, which has two relevant physical properties. First, you can write to a cell, but you cannot rewrite a cell - to change the value of a cell, you have to erase it first, and erase only works at the granularity of a whole block (typically 128 to 256 pages, with each page being 4 to 16 KB). Second, every cell has a limited number of program-erase cycles before it wears out, somewhere between a few hundred and a hundred thousand depending on the technology generation.

Those two facts shape everything the SSD controller does. The controller maintains a mapping table between the logical block addresses the operating system uses and the physical NAND blocks where the data actually lives. When the OS asks to overwrite a block, the controller almost never overwrites in place - it writes the new data to a fresh, already-erased block, updates the mapping to point at the new location, and marks the old block as "stale". A background garbage-collection routine eventually reads the still-valid pages out of partially-stale blocks, writes them to fresh blocks, and erases the old blocks so they can be reused. This shuffle is called wear-levelling, and it is constantly happening on every SSD whether you are writing to it or not.

The consequence for deletion: when the OS tells the SSD a block is free (typically via the TRIM command, which signals "the file system no longer needs the data at these logical addresses"), the SSD does not immediately erase the corresponding NAND cells. It marks them as invalid in the mapping table, which lets garbage collection prioritise them, but the bytes can sit in NAND for seconds, hours, days, or weeks depending on the drive's behavior and how full it is. On a drive that is largely empty, garbage collection rarely fires, and old data can persist for a very long time. On a drive that is heavily used, it gets reclaimed faster.

There is also the over-provisioned area to think about. Every SSD ships with 7-20% more raw NAND than the user-addressable capacity (a "1 TB" SSD typically has 1.07 to 1.2 TB of NAND inside it). The over-provisioned area is reserved for the controller's own use - bad-block replacement, wear-levelling working space, garbage-collection staging - and the OS cannot address it directly. Whatever sits in over-provisioned cells at any given moment is invisible to the OS, including any old data that got shuffled there by wear-levelling and has not yet been erased.

What "secure erase" means in 2026

Because of the architecture above, the old advice ("overwrite the drive a few times with random data") does not work on an SSD. The overwrite pattern gets written to fresh blocks, the old data sits in stale-but-not-yet-erased blocks, and you have spent a chunk of the drive's write-endurance budget for no security gain. The correct mechanism is built into the drive itself.

Almost every SSD shipped in the last decade implements encryption-at-rest internally, whether or not the user has turned on any visible encryption. The drive generates a Data Encryption Key (DEK), stores it in a small protected area of the controller, and encrypts every page written to NAND with that key before committing the bytes. The user does not see this; it is the drive's own engineering choice, intended to make secure erase instant.

A secure-erase command - ATA Secure Erase on SATA drives, the Sanitize command on NVMe, or the manufacturer's own utility - tells the controller to throw away the DEK and generate a new one. The actual NAND cells are untouched (well, they get erased lazily in the background), but every byte on the drive is now encrypted with a key that no longer exists. Mathematically, the contents are unrecoverable. The operation finishes in seconds, not hours, because no overwriting is happening.

This is the same trick that makes "Erase All Content and Settings" on an iPhone, "Factory Reset" on a recent Pixel, or "Reset this PC > Remove everything" on a BitLocker-encrypted Windows machine effectively instant. The OS is not zeroing out the flash. It is throwing away the encryption key that protected the user data, after which the encrypted bytes on the flash become noise. As long as the encryption was on from day one (which it is, by default, on every modern phone and most modern laptops), the throw-away-the-key operation is a complete delete in a way that overwriting could never be.

The practical implication is the inversion of the old advice: on an SSD, do not bother with multi-pass overwrites. Use the drive's secure-erase function or the OS's encrypted-reset, and the job is done.

Where this leaves you with a phone you are about to sell

The clean answer is short. On iPhone: Settings, General, Transfer or Reset iPhone, Erase All Content and Settings. The phone has been encrypting everything since you set it up, and this step throws away the key. On Android (recent versions): Settings, System, Reset options, Erase all data (factory reset). Same principle. On a Mac with Apple Silicon or a T2 chip: System Settings, General, Transfer or Reset, Erase All Content and Settings - the Secure Enclave erases the key. On Windows with BitLocker: a full reset that includes "Clean the drive" wipes the BitLocker volume key.

The unclean cases are the ones to actually think about. A laptop you bought before BitLocker was the default and you never turned it on. A desktop tower with a separate SSD and a separate spinning hard drive, where the spinning drive holds the photo archive and was never encrypted. A USB stick that has been carrying tax documents around for years. An external SSD that you used as a scratch drive for video edits. Any device where encryption was not on from day one, and the disposal moment is now. For those, the practical sequence is: enable full-disk encryption now (which re-encrypts the existing data), then run the secure-erase. For the truly paranoid case of a drive that may have held unencrypted high-stakes data and is being decommissioned, the only fully reliable option is physical destruction of the NAND chips - which is why corporate IT departments still keep a shredder for storage media.

Where this leaves you with the cloud

The cloud version of "secure erase" is mostly the recycle bin you already know about, plus a longer tail of consequences that no amount of bin-emptying can address.

What you can do:

Empty the bin explicitly when you mean to. iCloud Photos Recently Deleted, Google Photos Trash, Gmail Trash, Drive Bin, Notes Recently Deleted - each is a separate manual step. Do not assume the timer alone has run.
Revoke third-party app access. Apple ID, Google account, and Microsoft account dashboards all list the apps that have been granted access. Anything you no longer use, revoke - its cached copies are not under your control, but you can at least stop new data from flowing.
Delete the source before deleting the share. If a photo was in a shared album, removing it from the album before deleting it from your library reduces (though does not eliminate) the chance of cached copies persisting on the other side.
Account closure is the strongest version. Deleting a Google, Apple, or Microsoft account triggers a longer scheduled-purge window (usually 30 to 60 days, sometimes longer for compliance reasons), after which the company's stated policy is to remove all content - including the items in deleted-items folders, the machine-learning indices, the search indices, and the analytics history.

What you cannot do: delete the copy that is now on someone else's device. If you sent a photo, an email, or a message to another person, they have it. The encryption around the transit is irrelevant once the message arrived; the social fact of "they have a copy" is permanent. The piece on what end-to-end encryption actually covers walks through this in more detail; the short version is that the endpoint is always the weak point of any deletion story that involves a second person.

The habit that makes most of this go away

The single most useful thing you can do is turn on full-disk encryption on every device you own, on day one, and never turn it off. Once a device is encrypted at rest, the question of "what leftover bytes are sitting on the SSD" stops mattering, because all of those bytes are encrypted noise to anyone without the key. Deletion becomes much closer to its intuitive meaning. Disposal becomes a one-command operation. Loss or theft of the device stops being a data-leak event.

On iPhone and recent Android, this is on by default and you do not need to think about it. On Mac, check that FileVault is on (System Settings, Privacy and Security, FileVault). On Windows, check that BitLocker is on (Settings, Privacy and security, Device encryption, or for Pro editions, Settings, Storage, Advanced storage settings, Disks and volumes). On external drives that you carry around, use the OS's built-in encryption when you format them (APFS Encrypted on Mac, BitLocker To Go on Windows, LUKS on Linux). That single layer of encryption does more for the privacy of deleted files than any combination of secure-erase tools you could run later.

A short checklist

Empty the bin explicitly in any consumer app when you actually want a file gone, including iCloud Recently Deleted, Google Photos Trash, and the equivalents in mail and file storage.
Audit third-party app access to Photos, Files, Mail, and Contacts once a year. Revoke anything you do not actively use; their caches are out of your control.
Turn on full-disk encryption on every device you own - phone, tablet, laptop, desktop, external drives. This is the single highest-leverage habit on the list.
When you decommission a device, use the OS's encrypted-reset (Erase All Content and Settings, Factory Reset, Remove everything with clean-the-drive). Do not bother with multi-pass overwrite tools on SSDs.
For unencrypted SSDs being disposed of, enable encryption first (which re-encrypts the existing data), then run the manufacturer's secure-erase utility. For truly-high-stakes drives, physically destroy the NAND.
Accept the endpoint reality. Anything you sent to another person is on their device too, and your delete button does not reach there. The right time to think about this is before sending, not after.

Where this fits

Deletion is the back end of a privacy story whose front end is what you put on the device in the first place. The photo with embedded GPS coordinates that you wish you had stripped before sharing is covered in the photo-metadata piece. The PDF you thought you had redacted with a black rectangle is covered in the PDF-redaction piece. The conversation that survives long after the deletion timer is covered in the end-to-end-encryption piece. Together they are the working model: be careful what you save, be careful what you share, and know what delete actually does when you press it.

Privvert's tools all run locally in the browser - no upload, no account, nothing landing in someone else's recycle bin. The reasoning is on the privacy page, and the rest of the practical guides are on the blog.