Does APFS protect your files from bit rot?

By Ting Tze Chuen · Updated October 7, 2026

What is bit rot?

Bit rot, or silent data corruption, is when the data stored on a drive changes without anything reporting an error. The file still opens, the drive still mounts, and Finder shows the same size and date. But some bytes inside are different from what you saved: a band of noise across a photo, a glitch in a video, an archive that won't extract.

The word "silent" is the important part. A drive that fails loudly gives you a chance to act. Silent corruption is only found when someone opens the file, which may be years later, after every other copy has been overwritten with the damaged version.

What does APFS checksum, and what doesn't it?

Apple's own Apple File System Guide FAQ describes APFS's integrity protection like this: it uses copy-on-write to guard against damage from crashes and power loss, and it "uses the Fletcher's checksum algorithm for metadata operations." Nothing in that answer covers file contents.

The Apple File System Reference, the on-disk format specification, confirms it. Every APFS object header carries an o_cksum field, "the Fletcher 64 checksum of the object." The file extent records that point to your actual file data store an address, a length and an encryption ID, but no checksum.

In practice that means:

• Checksummed: the structures that describe the volume, folders, file names and where each file's data lives. If these are damaged, APFS can detect it.
• Not checksummed: the bytes inside your files. If a block of a video changes on disk, APFS reads it back and hands it to the app as if nothing were wrong.

The same FAQ explains why APFS doesn't store a second copy of metadata: on flash storage, the drive's translation layer often groups writes into the same NAND block, so a second copy written at the same time "affords no extra protection." APFS relies on the drive's built-in error correction instead.

How is that different from ZFS and Btrfs?

Some file systems checksum everything. In OpenZFS, each block's checksum is calculated when it is written and checked when it is read. Corrupt blocks "are automatically repaired if possible," using a mirror or RAID copy in the pool, and periodic scrubs read everything to find "latent media degradation (bit rot)." Btrfs works similarly: "Data and metadata are checksummed by default," and on mirrored profiles such as RAID1 a scrub repairs damage from the good copy.

Note the condition: self-healing needs a second copy. A single-disk ZFS pool can tell you a file is damaged, but has nothing to fix it from unless you've configured extra copies. Neither ZFS nor Btrfs ships with macOS.

Which file systems checksum your data?

HFS+, the older Mac format, has a journal that protects its structures from crashes, and Apple's HFS Plus Volume Format note specifies checksums only for the journal's own headers. exFAT, the format most cameras and cross-platform drives use, has checksums on a few metadata structures in Microsoft's exFAT specification, but none over file contents. On every format a Mac can write to without extra software, your file data has no checksum.

Doesn't the drive's own error correction catch this?

Mostly, but not completely. Apple notes that every SSD and hard drive in its products uses Error Correcting Code (ECC), which detects and fixes many read errors on the fly. ECC protects data inside the drive. It can't help if:

• the data was already wrong when it reached the drive, for example after a flipped bit in memory or a glitch in a cable, hub or card reader;
• the drive's firmware writes the right data to the wrong place, or reads back the wrong block;
• the error is in the controller or adapter between the disk and your Mac.

In each case the drive returns data it believes is correct. The best large-scale measurement of this is "An Analysis of Data Corruption in the Storage Stack" (Bairavasundaram et al., FAST '08). It studied 1.53 million disk drives in NetApp production storage systems over 41 months and found more than 400,000 checksum mismatches, which are corruptions the drives themselves didn't report. 0.86% of nearline (SATA) disks and 0.065% of enterprise-class disks developed at least one. The authors point out that silent corruption "cannot be detected or repaired by the disk drive itself." The only reason these errors were found is that the storage system kept its own checksum for every block.

Those are server drives, not Mac laptops, so don't read the percentages as odds for your own disk. The lesson carries over: the only way to know data is unchanged is a checksum kept outside the drive.

Where does corruption actually come from on a Mac?

In everyday use, many problems happen while data is moving, not only while it sits still:

• Transfers to external drives. A loose USB-C cable, an underpowered hub or a bus-powered drive that briefly loses power can damage a copy that Finder still reports as complete.
• Card readers and cards. A faulty reader or a worn memory card can damage camera files during an offload.
• Unplugging without ejecting. This hits exFAT drives hardest, since exFAT has no journal. See exFAT corruption on Mac.
• Aging or failing media. Sectors weaken, and drives left unpowered for long periods are rarely checked.
• Memory errors. A bit that flips in RAM before the data is written gets stored faithfully, with valid ECC, on the drive.

How do you protect your files from bit rot on a Mac?

You can't make APFS checksum your files, but you can add that layer yourself. These habits work on any drive and any file system.

1. Verify every copy when you make it. Read the copy back and compare it with the original, so you start with a known-good backup. Our guide to verifying a file copy on Mac covers five ways to do this.
2. Keep a checksum list. A list of SHA-256 hashes is the record APFS doesn't keep. Make one for a folder you want to protect:

   cd ~/Pictures/2026
   find . -type f ! -name '.DS_Store' -print0 | sort -z \
     | xargs -0 shasum -a 256 > ~/2026.sha256

3. Re-check against the list. Months later, or on a backup drive, run:

   cd /Volumes/Archive/2026
   shasum -a 256 -c ~/2026.sha256

   Each file is reported as OK or FAILED. Add --quiet to see only failures.
4. Keep several copies. The common 3-2-1 rule is three copies, on two different kinds of storage, with one somewhere else. A checksum tells you that a file is damaged; another copy is what you restore it from.
5. Re-verify periodically. Copies sitting on a shelf can decay unnoticed. Re-checking reads every byte, which catches both bit rot and failing sectors while you still have good copies elsewhere.

How VerifiedCopy fits in

VerifiedCopy covers the first and last steps. Copy & Verify writes your files to up to three drives in chunks, reads each chunk back and compares its SHA-256 hash with the source, rewriting any chunk that doesn't match. For older backups, Verify & Repair scans a backup against a known-good source chunk by chunk, rewrites only the damaged chunks, and can save a hash manifest of the scan. If you prefer Terminal, the shasum commands above do the checking part for free.