If your product images contain a photorealistic person generated entirely by AI, Amazon now expects the keyword contains-synthetic-performer to be embedded in that file’s metadata before you upload it. The practical consequence for anyone running an AI image workflow is narrower than the headlines suggest: no AI image generator writes this tag for you, and nothing in a standard generate-edit-upscale-export pipeline preserves it unless you put it there last. This piece is about where that step belongs in a tool stack, which parts of the stack quietly destroy it, and how the three implementation routes compare by team size. Data checked 2026-07-28.
This is not a command reference. It is the stack-design question that comes first.
What the Amazon AI image disclosure rule actually requires
Two facts need separating up front, because they carry very different evidence levels.
What is documented by reporting: Amazon notified third-party sellers on Wednesday, July 22, 2026 that qualifying product media must carry the metadata keyword contains-synthetic-performer, added with an IPTC-compatible editor before upload. CNBC
, which reviewed the announcement, reported it the following day; per eWeek
(2026-07-24), the scope covers product images and A+ content including videos and enhanced graphics, and Amazon said it will use the signal to display a disclosure on product listings where applicable.
What we could not verify ourselves: Amazon’s own guidance page for this sits behind Seller Central’s login. We tried on 2026-07-28. The help-hub article most commonly cited for it (GFXHCHYZRGJRBZA5) returns a login wall, and the Product image guide
returns only a JavaScript shell to an unauthenticated request, so we could not read its body either. Every statement in this article about Amazon’s requirement is therefore third-party reporting, not an official page we read. Treat the strings and scope as reported, not as quoted policy text.
The scope is much narrower than “we used AI”:
| Creative | In scope? |
|---|---|
| Photorealistic human generated entirely by AI, not based on a real person | Yes |
| Real model, retouched or enhanced with AI | No |
| AI-generated background or scene with no person in frame | No |
| Product-only shots, flat lays, packaging renders | No |
| Cartoon, illustrated, or stylized characters | No |
| TV, film, or video-game characters | No |
Reported scope as of 2026-07-28. Source: eWeek 2026-07-24.
The legal driver is the statute text itself. New York’s amendment to General Business Law § 396-b requires that a person who produces an advertisement for a commercial purpose “shall conspicuously disclose in such advertisement that a synthetic performer is in such advertisement”, but only “where such person has actual knowledge”. Civil penalties run to “one thousand dollars for a first violation, and five thousand dollars for any subsequent violation”. The statute exempts audio advertisements, advertisements for expressive works such as motion pictures and video games where the synthetic performer’s use matches its use in the work itself, and cases where AI is used solely for language translation of a human performer. The page carries no commencement date; eWeek reports it took effect June 9, 2026. Statute text checked 2026-07-28.
That actual-knowledge standard is why this lands on your workflow rather than Amazon’s. You know which renders came out of an image model. The platform does not, until you tell it.
One clarification worth making early, because the two get conflated: the Amazon requirement as reported is a keyword string in a metadata field. It is not C2PA, and it is not a Content Credentials manifest. C2PA provenance is a separate cryptographic-signing standard that some generators and platforms adopted independently; having it in a file does not satisfy the reported Amazon requirement, and nothing in the reported requirement mentions it. If your images already ship with Content Credentials, you still need the keyword.
Where the tag belongs in an AI image pipeline
Almost every AI image workflow we have looked at — including the six-tool stacks in our AI image generation tools comparison — has the same shape:
generate → cull → edit / retouch → upscale → resize + convert → upload
The instinct is to add “tag” near the front, right after generation, because that is where you know the image is synthetic. That instinct produces silently broken compliance. The tag has to survive every subsequent re-encode, and re-encoding is precisely where embedded metadata dies.
The correct position is one step before upload:
generate → cull → edit → upscale → resize + convert → TAG → VERIFY → upload
Two consequences follow, and they are the real workflow cost of this rule:
- Tagging is a batch operation on final exports, not a per-image habit during creation. Whatever folder you upload from is the folder that gets tagged.
- You need a read-back step. Writing metadata and confirming metadata are different operations, and only the second one tells you anything. A tool showing the keyword in its own panel is showing you its own database, not necessarily the bytes in the file.
If you keep a pre-upload checklist as part of your listing optimization workflow , this is a new line item in it — sitting alongside dimensions, white background, and file naming, not replacing any of them.
What actually strips the tag
We have not run an instrumented per-tool metadata benchmark, and will not publish pass/fail claims we did not measure. What is well established is the mechanism, and it is enough to design a stack around.
Metadata lives in a container inside the file — XMP in an APP1 segment for JPEG, an iTXt chunk for PNG. Any operation that decodes the pixels and writes a new file has to deliberately carry that container across. Some libraries do. Many, especially web-oriented ones optimized for output size, do not, because stripping metadata is a legitimate way to make files smaller.
IPTC’s own testing found this pattern years before AI images existed. Its social media test results record, site by site, that original-size downloads often retained embedded metadata while downscaled versions had it stripped. That was platform-side processing, not a resize you run yourself — but the mechanism is the same re-encode, which is in every Amazon image workflow.
Ranked by how often we would expect a step to drop metadata:
| Pipeline step | Risk to embedded metadata | Why |
|---|---|---|
| Web-based compressors and format converters | Highest | Output-size optimization strips non-pixel data by design |
| Upscalers and background removers | High | Output is a newly synthesized file, not an edit of the original |
| Resize / crop to Amazon dimensions | High | Re-encodes to new dimensions; whether metadata survives is library-dependent |
| Format conversion (PNG → JPEG, anything → WebP) | High | Metadata must be re-serialized into a different container |
| Desktop editor “Save As” / “Export As” | Varies by dialog | Many export dialogs have a metadata checkbox that defaults to off |
| Copying, renaming, moving files | None | The bytes are untouched |
| Amazon’s own ingestion pipeline | Unknown, and not yours to control | Which is why the tag has to be present at upload |
The practical rule: assume every step that produces a new file drops it, and place the tag after all of them. That assumption costs you nothing if it is wrong and saves the whole batch if it is right.
One consequence for anyone auditing existing listings: images pulled back down from a live listing have already been through Amazon’s pipeline. Use them to identify which creatives show AI-generated people, not to inspect what metadata you originally embedded. Tag and re-upload the master renders instead.
Three routes to writing the tag
The three routes are not competing products so much as three different answers to “how many files, and who is doing it”.
| Route | Typical tool | Fits | Batch ceiling | Where files are processed |
|---|---|---|---|---|
| Command line | ExifTool | Anyone comfortable in a terminal; scriptable pipelines | Whole directory trees, recursive | Local machine |
| Desktop GUI | XnView MP, digiKam, Adobe Bridge / Lightroom Classic | A handful of hero images at a time | Small batches, editor-dependent | Local machine |
| Browser | DiscloseTag | No installation available or wanted | Stated as unlimited on its site | In the browser, per its own documentation |
Route comparison as of 2026-07-28.
Command line: ExifTool
ExifTool is the reference implementation for this kind of work, and it handles an entire catalog in one invocation. Current release is 13.59, dated May 27, 2026 (checked 2026-07-28). Its supported-formats table lists JPEG, PNG, WebP, TIFF, MP4 and MOV as read/write with XMP creatable, which is the full range an Amazon workflow touches.
Stack fit: excellent above roughly 50 files per batch, and the only route that composes into an automated pipeline — a post-export hook, a Makefile step, a watched folder. If your workflow already involves any scripting, the decision is not close.
Stack cost: it is a command-line tool. For a seller whose creative workflow is entirely GUI-based, a terminal step is a real adoption barrier — and a half-adopted step produces a folder where some files are tagged and nobody knows which.
Desktop GUI: a Keywords panel
Any editor exposing the IPTC Keywords field can write this, because the field name is standardized even though menu paths are not. Adobe Bridge, Lightroom Classic, Photo Mechanic, XnView MP and digiKam all have one.
Check licensing before standardizing a team on one. XnView is distributed as freeware “for private or educational use (including non-profit organizations)”, and its site states that “If you intend to use XnView in a company, you must purchase a license”, from €29.00 for a single copy (checked 2026-07-28). Selling on Amazon is company use. digiKam is open source with no such distinction.
Stack fit: good for a few hero images, and genuinely good if the same person already lives in that application for culling and rating.
Stack cost: the highest silent-failure rate of the three, for a specific reason. Some applications hold keywords in a sidecar .xmp file or an internal catalog until you explicitly write metadata to the file. The panel shows the keyword. The file does not contain it. There is no error message.
Browser: a local tagging tool
The gap the first two routes leave open is specific: no installation, but more than a handful of files. DiscloseTag
is a browser-based tool built for that gap — it writes the contains-synthetic-performer value into the image’s XMP dc:subject field, applies container tags for video, and has a separate page for reading a file back
to check whether the tag is present. Its site documents JPG and PNG input up to 50MB per file and video up to 500MB, states batch size as unlimited, and describes processing as happening entirely in the browser with nothing uploaded. It also offers to draw a visible disclosure label into the image — a different requirement from the metadata keyword, and worth not conflating. The product is in beta and its site does not publish pricing or account requirements, so treat the commercial terms as an open question.
Stack fit: a seller or VA with no local tooling, no terminal, and a folder of thirty exports to clear before an upload window. It is also the only one of the three routes usable on a machine you do not administer.
Stack cost: what no browser tool can give you — and what no tool of any kind can currently give you — is confirmation that Amazon reads what was written. Nobody outside Amazon can test Amazon’s parser. The strongest verifiable claim available for any of these three routes is that the value lands in a standards-compliant XMP field that independent parsers can read back. That is worth having. It is not the same as a platform guarantee, and any tool in any route claiming otherwise is claiming something it cannot know.
Verification is the step people skip
Every route above shares one failure mode: a write that silently matched zero files, landed in a sidecar, or went into a field nobody reads. Make read-back a required step, not a diagnostic for when something already looks wrong.
From the command line, reading the field back on a tagged file returns your keywords one per line; an empty result is a failure, not a pass. The browser equivalent is a tag-checking page that reads the file and reports whether the tag is present.
Two habits make this cheap enough to actually do:
- Count, don’t spot-check. Compare the file count the tagging step reported against the file count in the folder. A mismatch is the only signal you get for a wrong path or a filtered-out extension.
- Verify after the last operation, not after tagging. If anything touches the files between tagging and upload — a last-minute resize, a colleague running them through a compressor — the earlier verification is void.
Video and A+ content
The reported scope names videos and A+ modules explicitly, and this is where stacks break down: video assets live in a different folder, get exported by different software, and are often handled by a different person.
Two things make video harder than stills. Container behaviour varies far more than JPEG, so a write that succeeds on one MP4 can no-op on the next without complaining. And transcoding rewrites the container, which puts the tagging step after final render and export rather than anywhere in the edit timeline. If your A+ video gets a final compression pass before upload, the tag goes on after that pass.
For AI spokesperson and avatar video this is not an edge case — a photorealistic AI presenter is exactly the category the rule names.
Stage-based recommendation
Beginner (under 30 SKUs, occasional AI lifestyle shots). A browser tool or a GUI editor you already own. At this volume, scriptable tooling will not pay back its setup cost. Take the read-back seriously — with small batches, a silent failure goes unnoticed until a listing is live.
Growth (30–100 SKUs, regular AI image production). ExifTool wired into the export step, with a browser-based checker as the second pair of eyes for whoever does not use the terminal.
Enterprise (100+ SKUs, dedicated creative operations). ExifTool as a non-optional pipeline stage, with a folder audit as the gate before upload. The real risk at this scale is not the mechanics — it is a contractor exporting from an undocumented tool, metadata gone before the files reach your upload folder.
The same principle holds across all three: one tagging step, in one place, immediately before upload, followed by verification. Spreading it across a creative workflow leaves you a half-tagged catalog with no way to tell which half is which.
What we’d change
We care more about pipeline design than tool choice here. All three routes write the same string into the same field. The failure mode that will actually bite sellers is a correctly-tagged file that gets resized afterwards, and no tool comparison saves you from that.
We are treating “unknown” as unknown. On any page readable without a login as of 2026-07-28, Amazon has not published which metadata container it reads, how it matches the string, or what happens to a listing that should have been tagged and was not. Anyone calling their tool confirmed Amazon-compatible is describing a test they could not have run.
This is a metadata question, not an AI-policy question. For the wider picture of where AI tooling creates compliance exposure, our AI tools risk guide covers the other fronts. This rule is unusual in being mechanically simple — one string, one field — and failing almost entirely on sequencing rather than judgment.
Disclosure: this article contains no affiliate links. amzfinder accepts free product trials from tools we cover and does not accept paid placement or sponsored reviews. Policy statements here are drawn from third-party reporting where Amazon’s own page is login-gated, and are labelled as such. Last updated: July 2026.