Metadata, embedded signal, visible label
A file can carry a signed manifest alongside the pixels, a signal mixed into the pixels themselves, or a label a viewer can read on screen. They are produced differently, they break differently, and a file can carry all three or none. As of 2026-09-12.
| Mechanism | Breaks when |
|---|---|
| Attached manifest | The container is rebuilt without copying it |
| Embedded signal | The picture is heavily compressed or cropped |
| Visible label | The frame is cropped or recomposed |
Inclusion rule. The three mechanisms the word marking covers. Platform-applied labels are a separate case. Order. Alphabetical by mechanism.
1Attached metadata: a manifest travelling beside the pixels
The first mechanism stores a record in the file container: what produced the asset, when, and sometimes a chain of what happened to it afterwards, signed so that tampering is detectable. Nothing about the picture changes, which is the mechanism's strength and its weakness at once.
It is the most informative of the three when it arrives intact, because it can carry structure rather than a single bit. It is also the easiest to lose, since anything that rebuilds the container without copying the record drops it silently.


2Embedded signal: something mixed into the picture
The second mechanism alters the pixels or the audio slightly so a detector can recover a signal later. Because it lives in the content rather than beside it, it survives operations that discard metadata entirely, which is the whole reason it exists.
Its limits follow from the same property. Detection is probabilistic rather than a lookup, heavy compression and cropping degrade it, and reading it requires whatever detector matches the scheme that wrote it. It also carries far less information than a manifest.
3Visible label: the one the audience actually sees
The third is a mark or wording rendered into the frame, or shown next to it by the platform. It is the only one aimed at a viewer rather than at a machine, and the only one that needs no tooling to read.
It is also the one most affected by framing and cropping, and the one whose placement is a design decision rather than a technical one. A corner mark on a vertical video can end up outside the safe area of a platform that recomposes the frame.
4What each one survives
A re-encode that rewrites the container usually keeps the picture and drops the manifest. A screenshot keeps whatever is visible and drops everything else. A crop can remove a visible mark and weaken an embedded signal while a manifest, if it survives at all, still describes the original.
Uploading through a platform that transcodes is the common case that touches all three at once. Assuming a file still carries what it carried at export, after it has been through someone else's pipeline, is the single most reliable way to be wrong about this.
5Why a single word for all three causes trouble
Conversations collapse when one participant means a signed manifest and another means a logo in the corner. They have different costs, different tooling, different survival behaviour, and a product that offers one has not necessarily addressed the other.
The habit worth building is to name the mechanism every time: manifest, embedded signal, visible label. It takes one extra word and removes most of the ambiguity from a question about what a file carries.
6Reading a product statement carefully
When a vendor describes what its outputs carry, the useful details are which mechanism, whether it is applied always or by setting, whether the setting is available on every plan, and whether it applies to downloads as well as to what is shown in the interface.
Those four points are what the generator table on this record tries to capture, in the vendor's own wording, with the page it came from and the date it was read. Where a vendor does not address one of them, the cell says so rather than inferring an answer.
7Checking a file rather than trusting a description
The description covers what a tool does at export. What a delivered file carries is a separate question, answerable only by inspecting the delivered file — the one that came out the far end of the pipeline, not the one on the workstation.
Doing this once per delivery route, rather than once per file, is usually enough: the route is what determines the outcome, and it changes rarely. When it does change, it changes for everything that goes through it.
8What this page is not
Nothing above says what anyone is required to do. Mechanisms are one thing; what a published instrument asks of a particular role in a particular place is another, and that material is recorded separately on this site with the clause and date it came from.
Which obligations apply to a given production is a judgement for whoever is accountable for it, usually with advice. This page only explains how the three mechanisms behave.
9Where the generator wording is filed
None of the three mechanisms belongs to any one vendor. What each generator publishes about its own outputs is recorded in the generator table, quoted from the vendor's page with the date it was read.
- What generators document — the wording each publishes, with its source
- Instruments — the text these mechanisms are discussed against
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: Keeping a record, Reading a plan table.