Adobe stock reads embedded XMP: title and keywords in the file

For video, Adobe Stock has two metadata fields that matter: a title and a list of keywords. There is no description field, and you do not pick the category. What Adobe's contributor documentation did not say, when we read it, is that Adobe reads both fields straight out of the file, from the XMP embedded in it, with no CSV and nothing typed in the portal.

This page shows what was measured, the limits each field has, and how to write the XMP so it reaches Adobe intact.

What was measured

On 2026-09-07, signed in to a live contributor account we work with and reading only, we opened the portal's In review tab. Twelve clips were in moderation. Each one showed the title and the keywords that had been embedded in its file as XMP, and the keywords were in the order they were written.

No CSV had ever been applied to those clips. Every attempt to apply one had failed while navigating the portal, so the embedded XMP is the only place their metadata could have come from. The portal also showed a category on each clip, "Animals", which Adobe had assigned by itself.

When we first read Adobe's contributor documentation, it described reading embedded metadata for JPEG and vector files only, and said nothing about MOV or MP4. So this is behaviour we observed, not behaviour Adobe documents. It could change without notice, and the portal is where a change would show first.

The fields Adobe reads, and their limits

The title limit is 200, not 70. Adobe's CSV requirements page says 70 characters. Adobe's CSV template and, decisively, the portal's own Upload CSV dialog say 200. The portal's field is what has to accept the title, so 200 is the number that counts. Commas are not allowed in it.

Because the title is Adobe's only text field, it can carry a full descriptive sentence rather than a short label, as long as it stays within 200 characters and has no comma.

The keyword limit is 49, not 50. Adobe's pages disagree, and its own CSV template settles it: "Max 49 keywords". Order matters, because Adobe says "the first 10 keywords carry the most weight in search results". Since the order in the file survives into the portal, the ten you write first are the ten that weigh most.

Paste a title below to see whether it fits Adobe's field, and the other marketplaces' fields, as written.

Writing the XMP with ExifTool

ExifTool writes XMP into MOV and MP4 files, and it has four behaviours on video that are easy to get wrong. All four were measured.

Always use explicit group prefixes. A bare -Keywords= does not land where you think: on a video it silently goes to XMP-pdf:Keywords, which is useless here. Write -XMP-dc:Title and -XMP-dc:Subject, with the group named.

Repeat -XMP-dc:Subject once per keyword. Repeating the tag builds a proper list (an rdf:Bag) with one entry per keyword. Joining the keywords with commas into one argument produces a single keyword literally named "a, b, c".

exiftool -o clip-tagged.mp4 \
  -XMP-dc:Title="Title sentence with no commas" \
  -XMP-dc:Subject="first keyword" \
  -XMP-dc:Subject="second keyword" \
  -XMP-dc:Subject="third keyword" \
  clip.mp4

The -o option writes a new file and leaves clip.mp4 untouched, which is the safe habit with footage you cannot shoot again.

QuickTime Keys:Keywords is the opposite. It is not a list tag (you can confirm with exiftool -listx -Keys:all). Repeating it overwrites, and only the last value survives, so if you write it at all, write one comma-joined string. The XMP list is what carries the meaning; the Keys block is a courtesy copy for players.

If a library drives ExifTool for you, check its composite rules. Some libraries apply the Metadata Working Group (MWG) rules by default, which re-route Title and Description into groups of their own choosing and undo your explicit prefixes. Turn them off when writing.

Two practical limits on video files:

• Every write is a full copy of the file. ExifTool needs about twice the file's size free in the file's own directory, not in the system's temporary folder. It is quick, around 600 MB/s on an Apple NVMe drive, so about 7 seconds for 4 GB.
• Use ExifTool 13.17 or later. Version 13.16 and earlier can corrupt QuickTime files that contain a wide atom with an invalid size.

A killed write leaves the original byte-identical, but it can leave *_exiftool_tmp files behind. Clear them out before the next run.

Write it last: ffmpeg strips XMP

So the order is fixed: every repair first, the metadata write last, immediately before the upload. If a repair has to happen after the write, copy the metadata back from the tagged file:

exiftool -tagsFromFile tagged.mp4 -XMP:all -Keys:all repaired.mp4

This is the order Rushlot follows: clips are checked and repaired first, you review the title and keywords, and the XMP is written as the very last step before the transfer.

Release fields: written, not known to be read

Adobe asks whether a clip shows recognisable people. XMP has a standard way to state it, the PLUS release fields. plus:ModelReleaseStatus set to MR-NAP means "not applicable": there are no recognisable people. MR-NON means the opposite, that there are people and no release covers them.

ExifTool 13.59 writes these correctly. Whether Adobe reads them has not been measured: we know Adobe reads Title and Keywords off the file, and that is a different claim. The field is still worth writing when it is true, because it states a fact about the footage on any marketplace. It is also the one field where being wrong is a statement about rights rather than a weak keyword, so Rushlot writes it only when nothing in the title, keywords or frames suggests a person, and otherwise leaves it for you to decide.

Same file, three different readers

The same XMP does not travel the same way everywhere. Measured on live contributor accounts (Adobe Stock on 2026-09-07, Pond5 and Shutterstock on 2026-09-11):

Write the XMP once, correctly, and it serves two of the three. Shutterstock needs its own route regardless.

A gap we have not closed

Rushlot never writes into your original file; it writes into the repaired working copy. A clip that needs no repair gets no working copy, so today it would be uploaded without its XMP. It has not happened on the account we work with, because every clip shot there needs a repair (an HEVC master or an audio track), but it is a known, open gap and we would rather you read it here than discover it in the portal.