Bit rot (also called data rot, data degradation, or silent data corruption) is when a file changes on a storage device without anyone touching it. A photo opens with a gray band across it, a video stutters at one point, an archive won't extract, and nothing ever reported an error.
It's real, but on modern drives it's rarer than the name suggests. Drives correct most read errors on their own. What you're more likely to find is damage from somewhere else: a copy that went wrong, a failing drive, or a cable that disconnected mid-write. The way you find any of them is the same, though: record a checksum for every file while it's good, and compare later.
TL;DR: Bit rot means files changing silently on disk. Hard drives and SSDs correct most errors internally, so true bit rot is uncommon; bad copies, failing drives, and interrupted writes damage more files. APFS checksums its own metadata but not your files, so macOS won't notice. To check a drive, make a checksum list once (find . -type f -print0 | xargs -0 shasum -a 256 > manifest.sha256) and verify it later (shasum -a 256 -c --quiet manifest.sha256). Fix damaged files from a second copy.
What Causes Bit Rot?
On a hard drive, data is stored as magnetized regions on the platter. Over years, and with heat, some of those regions can weaken until a bit reads back wrong. On an SSD, data is stored as an electrical charge in flash cells, and that charge leaks, faster when the drive is warm and unpowered (more on that in how long external drives last). Optical discs and tape degrade in their own ways.
Every modern drive stores error-correcting codes alongside your data. When a bit flips, the drive usually detects and fixes it on read, and you never know. Bit rot in the strict sense is when the damage gets past that correction and the drive hands back wrong data without an error.
In practice, files get damaged by a wider list of things, and you can't tell them apart from the result:
- A bad copy. A flaky cable, a hub, or a drive that disconnected during a transfer.
- A failing drive. Sectors going bad faster than the drive can remap them.
- An interrupted write. Unplugging without ejecting, or a power cut, while a file was being written.
- Memory errors. A bit flipped in RAM on its way to the disk. Rare on Macs, but not impossible.
- Software bugs. Rare, and the hardest to predict.
Is Bit Rot Real?
Yes, but the risk depends on how long data sits untouched and on what. A drive you use every day reads its data constantly, and the drive's own error correction and remapping keeps it healthy. The files at risk are the ones in a drawer or on an archive drive you open once a year, because damage there can build up for years before anyone looks.
The most useful framing is that you're not guarding against bit rot specifically. You're guarding against any change to a file you didn't make, and a checksum check catches all of them.
Does APFS Protect Against Bit Rot?
No. APFS, the default Mac filesystem, uses checksums to protect its own metadata (the structures that track where files are), but not the contents of your files. When it was introduced, Apple's engineers pointed to the error correction built into the storage hardware as the protection for user data (analysis by Adam Leventhal). Mac OS Extended and exFAT don't checksum file contents either.
So a Mac will happily open a damaged file and show you whatever is on disk. Nothing on macOS tells you a photo changed since 2019.
Filesystems that do checksum file data, like ZFS and Btrfs, can detect damage on every read and, with a second copy in the pool, repair it. That's one reason NAS boxes running them offer a "scrub" that reads every file on a schedule. If you keep a big archive on a NAS, turning on scheduled scrubs is the closest thing to automatic bit rot protection.
How to Check a Drive for Bit Rot on Mac
The method: hash every file once while you know it's good, save the list, and compare against it later. Any file whose hash changed has been altered. This works on any drive, any format, and needs nothing beyond Terminal.
Step 1: make the checksum list. Run this from the top of the drive or folder you want to protect (here, a drive called Archive):
cd /Volumes/Archive
find . -type f ! -name '.DS_Store' -print0 | xargs -0 shasum -a 256 > ~/Archive-manifest.sha256
That writes one line per file, a SHA-256 hash and a path, like this:
224d68f89ac646ce1af5dc5f0d477e26df0bd7f055cf761b63420bbe52fe8830 ./clip2.mov
Keep the list somewhere other than the drive it describes, and ideally keep a copy with your backups.
Step 2: check it later. Once or twice a year, or before you trust the drive for a restore:
cd /Volumes/Archive
shasum -a 256 -c --quiet ~/Archive-manifest.sha256
--quiet hides the files that pass. I flipped one byte in a test file on macOS 15.5 to see what a failure looks like:
./clip3.mov: FAILED
shasum: WARNING: 1 computed checksum did NOT match
Files you added after making the list won't be checked, and files you deleted will show as missing. Rebuild the list after you change an archive on purpose.
How long it takes. On an M3 Pro MacBook Pro, shasum -a 256 hashed a 1GB file in about 2.5 seconds, roughly 400 MB/s. That's faster than a hard drive can read (about 150-250 MB/s), so a check runs at the speed of the drive: about 1 to 2 hours per TB on a desktop hard drive.
What to Do When You Find a Damaged File
Replace it from another copy. That's the only real fix, which is why a checksum list is only half of the answer. A list without a second copy tells you exactly what you lost.
- Find the same file on your backup drive or in your cloud backup.
- Check that copy's hash against your list (
shasum -a 256 path/to/fileand compare). - Copy the good version over the damaged one.
- If several files failed, look at the drive itself: run Disk Utility's First Aid and watch for the warning signs of a failing drive. A cluster of failures points at hardware, not slow decay.
How to Protect an Archive From Bit Rot
- Keep at least two copies on different drives, ideally one offsite. Our 3-2-1 backup guide covers how to set that up.
- Verify copies when you make them. A file that's damaged on the way to the backup is as bad as one that rots there. Copy tools that compare checksums at copy time catch it immediately; this guide shows how to check a drive-to-drive copy.
- Keep a checksum list for archives and check it once a year.
- Plug archive drives in regularly, at least once a year, especially SSDs.
- Move to fresh drives every five years or so, verifying the copy before wiping the old one.
Tusk handles the second point: it checks every copy with a BLAKE3 hash when it makes it, across drives and cloud. It doesn't re-read archived files on a schedule to look for later decay, so for an archive you rarely open, keep the checksum list above as well (or use a NAS that scrubs).
FAQ
Bit rot is the slow, silent corruption of data on a storage device: bits on a hard drive, SSD, optical disc, or tape change over time without any error being reported, so a file that was fine years ago opens damaged. It's also called data rot, data degradation, or silent data corruption.
Yes, but it's uncommon, because drives detect and correct most bit errors with built-in error-correcting codes. It mostly affects data left untouched for years, such as archive drives in a drawer and unpowered SSDs. Bad copies, failing drives, and interrupted writes damage files more often than true bit rot does.
No. APFS checksums its own metadata but not the contents of your files, so macOS can't tell when a file's data has changed on disk. Filesystems like ZFS and Btrfs, often used on NAS devices, do checksum file data and can repair damage when there's a second copy.
Make a list of checksums while the files are good, then compare later. In Terminal, from the top of the drive: find . -type f -print0 | xargs -0 shasum -a 256 > ~/manifest.sha256. To check: shasum -a 256 -c --quiet ~/manifest.sha256. Any file listed as FAILED has changed since the list was made.
Only by replacing the damaged file with a good copy from somewhere else. Some formats can be partly repaired (a JPEG can sometimes be opened with a damaged section, a video can sometimes be remuxed), but the reliable fix is a second, verified copy. That's why archives need both a checksum list and a backup.
Not on its own. Classic RAID mirrors or stripes data so a dead drive doesn't take the volume with it, but it doesn't checksum file contents, so it can't tell which copy of a flipped bit is right. Filesystems with data checksums (ZFS, Btrfs) plus regular scrubs are what detect and repair bit rot on a NAS.