Bit rot: why digital files can become corrupted without warning

A photograph, save file, ROM, video, or project source can still appear normally in a folder even after an internal change has occurred. The problem may become visible only when the image shows blocks, the video stops midway, or an application refuses to open the content. “Bit rot” is an informal name for this kind of unintended degradation or corruption in stored data.

The term can make it sound as if bits simply age, but the result can have different causes: media wear, device or controller failures, errors during reads and writes, incomplete transfers, or software problems. In digital preservation, finding the precise cause is not always the first step. A more objective question comes first: does the file still contain exactly the same sequence of bits that was considered intact at the beginning?

How a checksum identifies a change

The practical answer is fixity checking. Software reads the file’s contents and applies an algorithm to generate a short digest called a checksum or hash. This value acts like a fingerprint: identical contents produce the same result, while altered data should produce a different one.

The reference checksum needs to be created when there is confidence that the file is correct. It can then be calculated again after a transfer or periodically during storage. Matching values provide evidence that the contents remained unchanged. A mismatch means the file changed and requires investigation.

The NIST Secure Hash Standard defines algorithms used to generate digests that can indicate whether a message has changed. Preservation tools and formats can store these values in databases, metadata records, or manifests. BagIt, described in RFC 8493, maps file paths to checksums and considers a package valid when its recorded values have been successfully verified.

Detection is not the same as repair

A checksum is not a copy of the file. It can reveal that a change occurred, but it does not contain enough information to rebuild a damaged photograph, video, or executable. The Digital Preservation Coalition recommends combining regular checks with multiple copies: when one version no longer matches the reference, another known-good copy can replace it.

This distinction separates three functions that are often confused. Storage keeps data available; redundancy provides another copy; fixity checking reveals whether each copy remains faithful. Keeping two corrupted files does not solve the problem, and calculating a checksum without retaining a healthy version only makes it possible to confirm the loss.

Synchronization is not automatically preservation either. It is useful for access and continuity, but it may propagate an unwanted deletion or change. Important content needs independent copies, enough version history to go back in time, and records of the integrity checks that were performed.

An intact file can still become inaccessible

Data corruption and obsolescence are different risks. The first changes binary content; the second occurs when the file remains intact but the software, codec, system, or hardware needed to interpret it disappears. The U.S. National Archives’ preservation program treats data integrity and format and media sustainability as related but distinct areas.

Preservation therefore does not mean placing something on a drive and forgetting it. Version 2.1 of the NDSA Levels of Digital Preservation, released in March 2026, presents preservation as a program that must be assessed and improved. Inventory, copies in separate environments, checksums, auditing, and format planning work as complementary layers.

How to apply the idea to a personal collection

The process can start simply: identify material that would be difficult to replace, make an additional copy in another location, generate reference checksums, and verify the files again at defined intervals. Any intentional migration, such as converting a format or reorganizing a package, creates a new state and requires new reference values while retaining a record of what was done.

For game collections, this can protect dumps, saves, mods, documentation, and tools, while projects such as MAME preserve hardware behavior in code. These are complementary problems: integrity keeps the bits trustworthy, while documentation and migration keep those bits understandable and usable. Preservation works only while both remain possible.