What file corruption actually is
Corruption is not damage to your data so much as damage to the agreement between the file and the program that reads it.
A file is a sequence of bytes. It only means something because a program knows how to read it. Every format is an agreement: the header sits here, this field is four bytes long, the index lives at the end, this marker means the file is over.
Corruption is any change that breaks that agreement. The file still exists, still occupies the same space, still has a name and an extension. It simply no longer matches the layout the reader expects.
Why file size tells you nothing
This is the part people find surprising. A 40 MB video with a destroyed index is still 40 MB. It copies normally, uploads normally, attaches to email normally, and syncs to cloud storage normally. Every tool that handles files by moving bytes around is perfectly happy with it.
Nothing notices until something tries to decode it. That is why corruption is so often discovered late, and why “the file is the right size” is not evidence that a backup is good.
How it happens for real
Five common causes, roughly in order of how often they show up.
Interrupted writes. Power loss, a crash, or a drive pulled out mid-copy. The header gets written, the index does not. Extremely common with removable media.
Storage degradation. Bad sectors on spinning disks, worn NAND cells on SSDs, bit rot in cold archives. Usually a handful of bytes, which is why filesystems with checksums exist, a defence explored in silent data corruption and the filesystems that catch it.
Transfer errors. A dropped connection mid-download, or the classic case of an FTP client in text mode translating line endings inside a binary file.
Software faults. A program crashing mid-save, or two processes writing the same file concurrently without locking.
Format drift. A file written by one version of an application and read by another that interprets the structure differently. Technically not corruption, but indistinguishable from it at the point of failure.
Two kinds of damage
It is worth separating them, because they behave differently.
Payload damage hits the content. A few bad bytes in a JPEG scan give you the smeared, colour-shifted look people associate with glitch art. The file still parses, it just renders wrong.
Structural damage hits the map. A JPEG missing its start-of-image marker does not render incorrectly, it does not render at all, because no decoder can work out where to start.
Most real-world corruption is a bit of both. Most naive corruption tools only do the first, which is why their output so often still opens.
What cannot be undone
Recovery tools work by finding redundancy: a surviving copy of the index, a recognisable header further into the file, RAR recovery records, a filesystem journal. Remove every source of redundancy and there is nothing to reconstruct from. Corruption at that point is genuinely one-way.
Which redundancy each format actually carries is worth knowing before you rely on it, and how archive repair tools actually work goes through them one by one.
This is the practical takeaway for anyone deliberately corrupting a file for testing. Keep the original. There is no repair function, here or anywhere, once the structure is gone. If you want to watch the transition from recoverable to unrecoverable, corrupt a file in your browser at each of the four levels and try a recovery tool after each one.