How to Delete Data Permanently on Any Device
You've probably got a phone, laptop, or old external drive sitting nearby with photos, passwords, work files, or years of app history on it. The delete button is easy, but the hard part is knowing whether the data is gone or just out of sight.
That's the core problem with how to delete data permanently. Permanent deletion isn't about making files disappear from a screen, it's about making them unrecoverable on the storage medium that holds them. On some devices that means overwriting blocks. On others it means destroying the encryption key, or even physically destroying the drive when the risk is high enough, as the British Federal Office for Information Security guidance on final deletion explains.
The mistake many individuals make is treating every storage type the same. I don't, because I've seen too many “deleted” files come back from the wrong drive, the wrong reset, or the wrong backup.
Table of Contents
- What Permanent Deletion Actually Means
- HDDs vs SSDs vs Encrypted Devices
- Wiping Data on Windows, macOS, and Linux
- Permanently Deleting Data on iOS and Android
- Cleaning Up Cloud Accounts and Backups
- Deleting Your Data Inside Specific Apps
- Verifying, Documenting, and Building a Repeatable Habit
What Permanent Deletion Actually Means
The first lie people learn about deletion is that emptying the trash means the data is gone. It doesn't. A normal delete usually removes the pointer to the file, not the file's underlying blocks, which is why recovery tools can sometimes still read old content until something else overwrites it.
The three things that actually make data unrecoverable
Overwrite is the classic route on magnetic drives. You replace the old data with new patterns so recovery software can't reconstruct what used to be there. The Open University's computing material frames this clearly for hard disks, along with degaussing and destruction as the other sure-fire options.
Cryptographic key destruction is the cleaner answer on encrypted devices. If the storage is already encrypted and you remove the key, the remaining bits may still exist physically, but they're no longer readable in practice.
Physical destruction is the final option when you need the highest assurance or when software wiping isn't possible. The BSI guidance says that if overwriting can't be done, the drive should be physically destroyed instead.
Practical rule: If the data lives on a drive you can still mount and read, start with a secure wipe. If the storage is encrypted and you control the key, destroying the key is often the faster path. If you can't trust the medium or the exposure is severe, destroy the hardware.
The most useful mental model is simple. Permanent deletion removes recoverability, not just visibility. That's why the right method depends on whether you're dealing with a file, a whole device, a backup, or a cloud copy.
HDDs vs SSDs vs Encrypted Devices
The storage medium decides the method. That's the part most generic guides get wrong, and it's why one-size-fits-all advice fails on modern hardware.
Choosing the right substrate rule
On a traditional HDD, overwriting is still the main software route. The National Cybersecurity Society guide on permanent deletion explains the basic workflow well enough for practical use, including overwriting target data or free space after deletion so old sectors are no longer recoverable. That same guide also makes the important point that deleting a file and emptying the Recycle Bin only removes directory pointers.
On an SSD, the story changes. Wear leveling, controller remapping, and flash translation can keep logical overwrites from touching every physical location. That's why secure erase or a drive-specific cleaning tool is more trustworthy than repeated file overwrites on flash.
On a fully encrypted device, the strongest option is often to make the key inaccessible. If the data is encrypted at rest and the encryption is sound, removing the key can be quicker and cleaner than trying to overwrite every trace in flash.
| Storage type | Best deletion method | Why software overwrite alone falls short | Built-in tool to use |
|---|---|---|---|
| HDD | Secure overwrite or physical destruction for high assurance | Deleted files can still sit in free space until the blocks are overwritten | Manufacturer wipe utility or OS disk wipe |
| SSD | Drive secure erase or full-disk cleaning | Wear leveling and controller remapping can keep overwrites from reaching every flash cell | Secure erase from the drive maker or platform reset tools |
| Encrypted device | Destroy the encryption key, then reset or wipe | The data may still exist physically, but it's no longer readable without the key | FileVault, BitLocker, or device encryption reset path |
For a deeper look at how encryption changes the risk profile, see the overview on encrypted data storage.
On SSDs, I stop trusting folklore fast. If a guide says “just overwrite it three times,” I treat that as HDD-era advice unless the device type is explicitly magnetic.
The decision rule is short. HDD, overwrite. SSD, secure erase. Encrypted device, destroy the key or use the strongest reset path available. If the data is too sensitive to trust any of those, destroy the storage medium.
Wiping Data on Windows, macOS, and Linux
The operating system matters, but only after you know the substrate. A Windows reset on an SSD, a Mac erase on FileVault, and a Linux shred command are not interchangeable tools. Each one has different limits, and the right choice changes with the drive type.
Windows and macOS
On Windows, the built-in reset path is the first place to look when you're retiring a laptop or handing it off. Use the option that includes clean data rather than a quick reset, because a basic reset is not the same thing as a secure wipe. If the device manufacturer offers a secure-erase utility, that is often the stronger choice for SSDs and for machines that need a more explicit sanitization step.
Quick format is a trap. It makes the volume look empty, but it does not make the underlying data unrecoverable on its own.
On macOS, the stronger common path is to make sure the drive is encrypted first, then erase the device through the built-in reset flow. On Apple Silicon Macs, Erase All Content and Settings is the modern route. On older Intel Macs, the workflow is different, and the older recovery and security utilities still matter for a full handoff.
Linux and the limits of command-line tools
Linux gives power users more direct control. shred is useful for files, while dd and hdparm are used in full-drive workflows. The catch is simple. These tools are still most relevant to HDD-style deletion patterns, and they should not be the only answer on SSDs.
The permanent file deletion guide from the National Cybersecurity Society is blunt about common failure modes, especially wiping the wrong partition, relying on quick format, or assuming software deletion alone is enough.
Verification check: After the wipe, try opening the target volume or file through normal tools. If the system can still mount the old data or recover it from the obvious path, the wipe was incomplete.
If you are erasing a Linux system disk, confirm the device type first and do not assume the same wipe command is right for every drive. That habit prevents a lot of false confidence and a lot of accidental data retention.
Permanently Deleting Data on iOS and Android
Phones are where people keep the most personal material, and they're also where deletion mistakes happen fastest. A factory reset helps, but the key difference comes from whether the device was encrypted before the reset and whether every linked account and removable card was handled too.
The encrypt then reset pattern
On modern iPhone and Android devices, encryption makes a factory reset much stronger because the leftover bits are useless without the key. That's why the practical sequence is to encrypt first, then reset, rather than relying on the reset alone.
That guidance lines up with the BSI's advice on smartphones, where a factory reset erases user data and apps, but stronger assurance comes from encrypting or overwriting with non-critical data before the reset. It's a useful benchmark for older devices too, especially when you don't know how the phone was used before you got it.
The steps people forget
Before the phone leaves your hands, handle the parts that don't disappear with a reset:
- Sign out of cloud accounts: Remove iCloud, Google, Samsung, and carrier-linked access so the device can't still sync or be located after the wipe.
- Remove SIM and microSD cards: The device recycling guidance makes this explicit, because those cards can survive a phone reset intact.
- Revoke trusted-device status: Take the phone out of your account's trusted devices list so it can't keep acting like an approved login device.
- Unpair accessories: Smartwatches and other paired gear can keep carrying fragments of your data or your account access.
A reset is one step, not the whole process. If external storage or account access is still active, the phone isn't fully sanitized.
The safest handoff sequence is simple. Back up what you need, sign out, remove SIM and card storage, wipe the device, and then check that the phone no longer appears as a trusted device in your account. That's the difference between a reset and a real retirement.
Cleaning Up Cloud Accounts and Backups
Local deletion is only half the job. The data you worry about often survives in cloud storage, synced folders, version history, or vendor backups after the device copy is gone.
Soft delete is not the same as purge
A soft delete usually hides the item from view. A permanent purge is different, because it removes the data from the retention path where it might still be restored later. The distinction matters in cloud systems because the main file, the trash copy, and the backup copy can all live separately.
Google Cloud's Gemini Enterprise documentation explicitly distinguishes a normal delete from a permanent purge workflow, which is a good reminder that cloud deletion has its own rules. That same basic logic applies to consumer platforms too, even when the interface makes everything look like a single trash can.
A practical workflow for cloud cleanup is straightforward:
- Empty the visible trash or deleted items folder.
- Check version history, archives, or synced-device folders.
- Review backup locations and account-level retention settings.
The MicroTrack export guide is a useful example of the kind of pre-delete thinking that helps here, because export comes before removal when you still need a copy for yourself.
Where old copies usually hide
Cloud copies often survive in places people forget to check. That includes attached backup services, desktop sync folders that mirror deleted files back from another device, and old account snapshots that weren't part of the main delete action. This is why cloud deletion needs a separate review from the local wipe.
If your data lives in a SaaS tool, treat that tool as its own storage surface. Delete the content there, then check whether the account still has history, exports, or backup retention you don't control directly.
For people managing app-based records, the cloud is often the primary source of residual risk. The local phone or laptop is gone, but the account copy is still sitting on a vendor server.
Deleting Your Data Inside Specific Apps
A lot of people clean the device and miss the app. That's a mistake, because many modern apps keep data in three places at once, the in-app record, the account record, and the export or backup record.
The export, delete, account pattern
For app-specific deletion, I use the same sequence every time. First, export what you want to keep. Second, use the app's in-app delete function. Third, remove the account if the service supports account-level erasure, then confirm the data is no longer reachable from a fresh login.
That sequence fits the way many wellness, journal, and tracker apps are built. The app may let you clear entries inside the interface, but the account can still hold history, synced notes, or stored settings behind the scenes.
MicroTrack is one concrete example of that workflow. Its product description says you can export your history as CSV, and its privacy policy says you may request deletion of your account and associated data by contacting the company. That makes it a good model for the broader pattern, because export and deletion aren't treated as the same action.
The MicroTrack journal overview is a helpful reference if you're comparing how personal-data apps handle history, structure, and removal.
What to check in other apps
The same logic applies across most modern apps:
- Health apps: Look for export, in-app delete, and account deletion as separate controls.
- Journal apps: Check whether old entries live in local storage, cloud sync, or both.
- Tracker apps: Verify whether deleting a record removes it from the server or only from the current device.
If an app has a “delete” button but no clear account-erasure path, assume the service may still retain some form of data until you verify otherwise.
One reusable rule saves time. Never stop at the visible delete button. Export first if you need a copy, delete inside the app, then close the account if the service keeps a long-lived profile.
Verifying, Documenting, and Building a Repeatable Habit
A wipe that cannot be checked is only an assumption. Verification matters because tools can report success and still leave recoverable traces behind, especially if the wrong volume, card, or partition was targeted.
The short checklist that prevents mistakes
Verification. Open the target through normal tools, or, if you used secure erase, confirm that the drive behaves the way it should after the operation. If obvious recovery paths still show data, the job is not finished.
Documentation. Record the date, device identifier, method used, and tool version. If you ever need to prove what happened, that record matters more than memory or a vague recollection of the steps.
Repeatable habit. Before every deletion, back up what you need, sign out of accounts, and remove SIM or memory cards. Those three actions catch the mistakes that keep coming up in real device work.
Keep one principle in mind. Verification tells you the wipe ran, while documentation tells you what was done and on which device.
Keep the process boring and consistent. The fewer guesses you make at the end of a wipe, the less likely you are to leave a recoverable copy behind.