IPTC photo metadata: the fields that matter

The point of embedded photo metadata is that the description travels with the file. A caption in a spreadsheet is lost the moment the image is emailed to a designer. A caption written into the file arrives wherever the file arrives.

The three groups

Embedded photo metadata divides into three kinds of statement, and keeping them apart is the whole discipline.

Descriptive fields say what the picture shows: headline, description or caption, keywords, the people and places depicted. These are what searches run against.

Administrative fields say where the file came from and what to do with it: creator, capture date, location of capture, job identifier, special instructions.

Rights fields say what may be done with it: copyright notice, credit line, usage terms, and a pointer to the licensor.

A field belongs to exactly one group. Writing the licence terms into the caption, or the photographer's name into the keywords, is the most common way libraries become unsearchable — the fields stop meaning anything specific, and every search has to look everywhere.

The eight that earn their place

Description (caption). The sentence a reader would need to understand the frame. Written at ingest, this becomes the starting point for every published caption the image ever gets.

Headline. A short handle for the picture, not the headline of any story it ran with. Useful in list views; harmful if it is used to store the story's headline, because the picture will run again with a different one.

Creator. The photographer, spelled the way they spell it. This is the field that credit lines are generated from, so an inconsistency here becomes a published inconsistency.

Copyright notice. Who owns the rights. Blank means unknown, not public domain, and a library that leaves it blank by default has thrown away the distinction.

Credit line. How the source wishes to be named in print. Frequently different from the creator — a staff photograph may credit the title, an agency frame credits the agency.

Date created. The date the photograph was taken, which is not the date the file was made. Files get re-exported; the capture date should not move when they do.

Location created. Where the shutter was pressed. City and country at minimum, more if the picture needs it.

Keywords. Controlled terms, not free text. This is the field that decides whether anybody finds the image in three years.

Where the fields live

Embedded metadata is written inside the file, in one of two arrangements. Older editorial workflows put it in a legacy block inside the image; current ones use an XMP packet, which carries more and is better defined.

Some formats cannot hold either. Camera raw files are frequently left untouched on principle, so that the original is never rewritten. In those cases the metadata goes in a sidecar file beside the image, carrying the same base name and a different extension.

Sidecars work, but they are two files pretending to be one. Move the image and leave the sidecar, and the description is gone with no error message. Where a sidecar is unavoidable, the pairing has to be enforced by the system that stores them, not by the person moving files.

What survives the journey

This is the part that surprises people. Metadata is not durable in transit. Several routine operations strip it:

• Resizing or exporting through tools configured to discard metadata
• Posting through platforms that re-encode images on upload
• Converting between formats where the target carries a different metadata model
• Pasting a picture into a document and extracting it again

The practical consequence is that the copy on the desk may be fully described while the copy that reached the designer is blank. There is no way to tell by looking.

The defence is to keep the master in the library, distribute derivatives from it, and never treat a returned file as authoritative. If a file comes back from outside with metadata, that metadata is a claim, not a record.

Filling the fields without wasting the day

Nobody types eight fields per image at ingest, and a workflow that requires it will be abandoned in a week.

What works is filling the fields that apply to a whole shoot once — creator, copyright, credit, date, location — and then writing only the description and keywords per frame. On a typical assignment that reduces the per-image work to a sentence and a handful of terms.

The keywords should come from a fixed list. Free typing here produces the synonym sprawl that makes a library progressively harder to search as it grows: plural and singular of the same term, two spellings of the same place, three ways of writing the same job title.

Conclusion

Embedded metadata is worth exactly as much as its worst-filled field. Eight fields, filled consistently, with the descriptive, administrative and rights statements kept apart, will carry a picture library for decades. Forty fields filled inconsistently will not survive its first migration.