What survives being re-encoded
Three entries address durability and they split by layer, not by opinion: the in-picture watermark is stated to survive cropping, filters, frame-rate changes and lossy compression, while both entries describing metadata warn that it can be removed. As of 2026-09-22.
| Entry | What is published | Detail |
|---|---|---|
| SynthID | Designed to survive | Cropping, filters, frame rate, lossy compression |
| Amazon Nova Reel | Checkable unless removed | The guide says a check works unless the metadata has been removed |
| SceneMixer | Watermark stated to resist compression | The terms call the invisible layer compression-resistant; the guide warns metadata can be stripped |
| Everyone else | Not addressed | No durability statement published |
Inclusion rule. Entries whose public pages say anything about durability. Silence is recorded as not addressed rather than as fragile. Order. Entries that publish a durability statement first.
1These two are describing different layers, not disagreeing
A watermark embedded in the pixels and a field written into the container behave completely differently under re-encoding. The first has to be attacked to be removed; the second disappears when a tool rewrites the file without copying it across. Both statements can be true at once because they are about different places in the same file.
The reason to put them on one page is that they are routinely quoted as if they were comparable claims about the same thing. They are not, and a reader who merges them ends up expecting metadata to be robust or expecting a pixel watermark to be strippable by a re-export. The agreement between the two metadata entries is the useful part: one vendor warning about an editor and another warning that a provenance check works unless the metadata has been removed are the same warning, written by parties with no reason to volunteer it.
2A durability claim is only as good as the attacks it names
Cropping, filters, frame-rate changes and lossy compression is a specific list, and lists like that describe ordinary handling rather than deliberate removal. Nothing published claims the scheme survives someone trying to defeat it, and reading that in would be inventing a stronger claim than the vendor made.
This site records the list as given. It does not test it, and it does not rank it against anything, because there is nothing else in the record making a comparable claim.
3The practical advice both statements point at
Whatever the file leaves the generator with, an edit suite is where it is most likely to be lost. That is true of metadata for certain, because two of the vendors here say so, and it is the step a production controls rather than the one a vendor does. It is also why an entry that carries both a signal in the picture and a record in the container is in a different position from one carrying only the second.
Which is a workflow observation rather than a finding about products, and it is the only one on this page that applies regardless of which generator was used.
- MetadataThe guide tells publishers to keep whatever content credentials or generation metadata the tool writes, and warns that re-encoding can strip themdescribed but not enumerated
- RobustnessDesigned to stand up to cropping, added filters, changed frame rates and lossy compressionas stated by the vendor
- DurabilityThe user guide adds that such a check should indicate the file was generated unless the metadata has been removedthe vendor's own caveat
4Sources
Every line is read from the vendor pages listed on the support table, checked 2026-09-22. What earns a row is set out in the protocol. Nearby: Checking a file, At which step, Two marks at once.