Invisible watermark: a signal inside the picture
An invisible watermark is carried by the picture and perceived by nobody. It is designed to survive handling that would remove an attached note, and it is worth nothing to a reader without something that can read it. As of 2026-09-22.
| The term | Invisible watermark |
|---|---|
| What it names | A signal embedded in the picture, imperceptible to a viewer |
| What it is not | Metadata attached to the file around the picture |
| Where the register uses it | The file-contents column, where a vendor names one |
Inclusion rule. Words this site uses in a narrow sense, where the ordinary sense would lead a reader to misread a cell. No vendor statement appears on this page. Order. Fixed order: what the word names, what it excludes, then where it is used here.
1Why it inverts every column this register was built around
The four fields assume a familiar shape: a mark a viewer sees, a plan that takes it away, a file that carries nothing. An invisible watermark reverses all three. Nothing is visible, so the visible-mark columns have no content. No tier lifts it, because removing it would defeat its purpose. And the file is the only place it exists.
Recording such an arrangement as a no in a removal column would be false; recording it as a yes would be worse. So entries built entirely around one are kept apart from the generator table, and generator rows that name one fill the file column and leave the commercial ones empty.
2Durability runs the opposite way from a manifest
Because the signal lives in the picture, it travels through new containers, new codecs and stripped metadata. What threatens it is anything that alters the picture enough: heavy compression, a filter, a change of frame rate, a crop. Those are the transformations a scheme's own documentation talks about surviving.
A manifest has the reverse profile: readable by ordinary tools, removable by an ordinary re-encode. A file can carry both, and one handling step can leave one intact and destroy the other, which is why the register keeps them as separate facts even when one vendor names both.
3A claim about one is only as good as its reader
A vendor saying its output carries an invisible watermark is making a claim nobody outside can confirm without a tool. Where a public reader is named, the claim becomes something a recipient can act on. Where detection is described as internal, the signal is real and the capability belongs to the vendor.
That is the difference the file-contents column cannot show on its own, and it is why the register records detection routes as separate facts. A filled cell says something is in the file; only a named route says anybody else can find it.
Nothing on this page is a vendor statement; the values it helps read are on the support table, with the page and the date each one was read from. See also the free tier column, metadata against watermark. Nearby terms: content credentials, provenance manifest, generation metadata.