The Getty ESP CSV, Field by Field

The metadata CSV is the least documented part of contributing to Getty Images and iStock. The columns are simple enough, but the details that decide whether an import works — the date format, the file encoding, which fields Getty fills in for you, and why a row occasionally vanishes on the way into DeepMeta — are spread across a login-gated help centre and a third-party desktop app. This is what we learned building an exporter for it, field by field.

The file, column by column

The layout that both iStock's ESP upload and DeepMeta accept is seven columns, in this order:

The created date is the field that actually gets files rejected

Two things about this column are worth more than everything else on this page.

The format is MM/DD/YYYY, and that is not a style preference

ESP accepts MM/DD/YYYY and nothing else. DeepMeta is more permissive. We tested its importer directly with a four-row probe, one format per row, imported for real rather than inferred:

So the intersection is ESP's format, and one file genuinely serves both destinations. If you are generating this CSV yourself, write MM/DD/YYYY even though ISO is the saner format — the narrower requirement is the one that has to win.

Where the date should come from, and where it must not

The obvious source is the file's timestamp. It is also the wrong one. A file timestamp records when the file was last written, so a retouched or re-exported photo carries a date months after the shutter fired. Sampling a real working drive, we found 12 of 15 files carried a wrong date that way — one April shoot was going out stamped December of the same year.

This is not cosmetic. Agencies compare the created date against the date written on the model release attached to the submission. If the two disagree, the file is rejected — and the reviewer is not going to guess which of the two dates was the honest one.

The rules that follow from that:

• For photos, read EXIF. DateTimeOriginal first, then CreateDate, DateTimeDigitized and ModifyDate as fallbacks. That is the shutter, which is what the release is dated against.
• If there is no EXIF date, ship the column blank. A PNG, a WebP, a screenshot or a file whose metadata was stripped has no shutter time, and a blank cell is safe — Getty reads what it can from the file itself. A file timestamp in that cell is a confident wrong answer, which is worse than no answer.
• Treat the date as text, never as a date object. EXIF stores wall-clock time with no timezone. Parse and reformat it and an evening shot can move to the next day.
• Video is the exception, and it has no good answer. A rendered clip has no EXIF, and the only date inside the container is the render. One of our own January shoots rendered in September and would have gone out stamped September. There is no better source in a rendered export, so this is the one field a video contributor has to correct by hand.

Keywords: the vocabulary, and the slots not to waste

Getty runs a controlled vocabulary — a fixed dictionary of approved terms rather than free text — with a cap of 50 keywords per file. Terms outside the dictionary are not simply weaker, they are largely inert. Our guide to the Getty controlled vocabulary covers how to work inside it.

The less obvious point is which keywords you should not spend slots on, because Getty applies them itself when the file is ingested:

• Technical and format facets — Photography, Color Image, Horizontal and Vertical, and their video equivalents. These appear on the overwhelming majority of published iStock files because Getty stamps them at ingest, not because contributors typed them.
• Ethnicity terms, which Getty takes from the model release attached to the submission. The paperwork is the authoritative source; a photograph cannot settle the question and neither can a keyword list.

Their absence from your CSV is not a gap. We spent real time auditing exactly this before measuring it properly and concluding that the data is applied downstream of the contributor.

Two encoding details that break imports silently

The byte-order mark

Save a CSV from Excel as "CSV UTF-8" and it carries a byte-order mark: a few invisible bytes at the very start of the file. ESP matches its columns by reading the first header cell, and the mark glues itself onto that cell — so the header stops being file name and the importer finds nothing.

The frustrating part is that this is agency-specific rather than universally wrong. Dreamstime expectsthe Excel flavour with the mark. One agency needs it, Getty breaks on it, which is why a single "export CSV" button that serves every destination is a trap.

The trailing newline

Both ESP and DeepMeta can drop or truncate the final record when the file does not end in a newline character. The symptom is specific and maddening: everything imports except the last file in the batch, every time, with no error message. We shipped this bug in our own exporter once — the library we use omits the final newline by default — and now force it on every file we write.

DeepMeta: verify after every import

DeepMeta is the desktop tool most Getty contributors use to prepare and submit, and its CSV import is where the same file can behave differently on two consecutive runs. In four days we saw three separate incidents, each with a file we could prove was correct:

1. The created date column landed empty on all 36 rows of a batch, from a CSV that carried a valid MM/DD/YYYY date on every row.
2. One clip out of 26 received no keywords at all — filename byte-identical to the file on disk, row present, quoting clean, all 26 keywords valid vocabulary.
3. The same thing again, on a different clip, in a different batch.

We tested the obvious hypotheses rather than arguing about them. Was it the row's position in the file? We re-exported the same 26 rows in reversed order, putting the failing clip first and a working clip last. Everything imported. So it is not position, and it is not that row's content either — the import itself intermittently drops things. Re-importing the identical file fixed it every time.

The practical consequence is a habit worth building: after importing a CSV, check that every file actually received its keywords and date before you upload. The failure is silent, and the cost is an asset reaching Getty with no metadata — which nobody notices until it never sells. Do not go hunting for a fault in your own file first; we ruled ours out three times.

qHero: the four-column variant

If you submit through qHero instead, the layout is different and stricter about it. qHero's importer expects exactly four columns — file name, title, description, keywords — and rejects the wider ESP layout outright. Keywords are comma-space separated there.

One detail specific to vector work: qHero matches a deliverable by its .eps filename. If your row names the .jpg preview you generated, the importer errors out. The extension in the CSV has to be the extension of the file you actually upload.

Pre-upload checklist

1. Filenames in the CSV match the uploaded files exactly — extension included, no leading or trailing spaces.
2. Dates are MM/DD/YYYY, or blank where there is no EXIF date.
3. Video dates checked by hand against when the shoot actually happened.
4. Keywords inside the controlled vocabulary, 50 or fewer, without the facets Getty adds itself.
5. File saved without a byte-order mark, ending in a newline.
6. Brief code filled only if the files were shot for a brief — and the brief-specific rules are a separate matter, which we covered in are Getty Custom Content briefs worth it.
7. After import, every row verified as having landed with its keywords and date.

Sources & further reading

• Getty Images — Preparing your content (contributor login required)
• The complete Getty & iStock contributor guide
• The Getty controlled vocabulary, explained
• How every stock agency wants your metadata
• Stock video specs and metadata across nine agencies