What one ordinary upload does to a file
Uploading through almost anything rewrites the container. The picture and the sound survive, in a degraded form; whatever was stored beside them may not. This is the most common event in the life of a published file. As of 2026-09-12.
| Part of the file | What the rebuild does to it |
|---|---|
| The picture or the sound | Re-encoded, usually at lower quality |
| Anything rendered into the frame | Survives, subject to reframing |
| A signal mixed into the content | Survives, weakened by compression |
| A record stored in the container | Copied only if the tool chooses to |
Inclusion rule. Effects of a re-encode performed by a delivery platform on upload. Order. From the part that always survives to the part that often does not.
1A rebuild is routine, not adversarial
Nobody is attacking the file. A platform re-encodes because it has to serve many devices, and it builds a new container because that is how encoders work. Copying auxiliary records across is optional and frequently skipped.
So the durability question that matters is not what survives an attack. It is what survives an ordinary Tuesday, and the answer differs sharply between mechanisms that live inside the content and beside it.
2Derivatives multiply the problem
Thumbnails, previews and alternate renditions are each generated from the upload, and each generation is another rebuild. A viewer often sees a derivative rather than the file that was uploaded.
Which means a check performed on the master answers a question nobody asked. The interesting file is the one an audience receives, and it may be several rebuilds downstream of anything a production ever inspected.
3The asymmetry is the whole design problem
The most informative record is the easiest to lose; the least informative signal is the hardest. Nobody would choose a single bit hidden in the pixels if a signed manifest survived delivery.
Which is why some products apply both. Two mechanisms on one file means the stripped copy still says something and the intact copy says a great deal, at the cost of doing the work twice.
4Checking a route beats checking a file
A route determines the outcome for everything that passes through it, and routes change rarely. Establishing one once is usually enough, and it is far cheaper than inspecting individual deliverables.
When a route does change, it changes for everything at once, which is both the risk and the reason the check is worth repeating whenever something upstream is replaced.
Background on mechanism and practice. Nothing here is attributed to a product, and nothing here is a reading of any instrument. The sourced material is on the generator table. Related: Safe areas and crops, Thresholds.