Photo Metadata Explained: EXIF, IPTC, XMP, Keywords and Ratings

Start with the photograph and everything travelling with it

A client receives a beautifully edited photograph, but the credit has disappeared. A second photographer’s images sort into the wrong part of a wedding. A selection looks rated in one application and unrated in another. These can all be metadata problems, even when the image pixels are perfectly intact.

The useful question is not simply “does this file have metadata?” Ask which information, stored where, interpreted by which application, for which next task? A caption in a catalog, a keyword embedded in a JPEG and a processing instruction in a sidecar can describe the same photograph while having different storage and delivery requirements.

This guide follows an illustrative job through capture, organization and handoff. Imagine a small assignment with camera RAW files, companion JPEGs, an editing catalog and a delivery folder. The examples are invented teaching records, not a claim that Lightbox Pro writes every field discussed. The goal is to build a metadata packet you can inspect and transfer deliberately.

EXIF, IPTC and XMP answer different questions

EXIF describes image and capture information. Exposure time, f-number, focal length and GPS coordinates are examples in Adobe’s EXIF property mapping. Fields may be absent, altered or interpreted differently; a recorded camera setting is evidence to consider, not proof of authorship, correct focus or the real-world accuracy of a clock.

IPTC Photo Metadata defines descriptive, administrative and rights-related properties. XMP is an extensible metadata model and representation that can carry IPTC properties alongside other namespaces. They are not three mutually exclusive switches. A single photograph can contain Exif information and IPTC information represented through XMP. Adobe’s XMP specification overview explains the distinction between the model, serialization and storage.

Scroll across to compare the roles.

A program’s “Info” panel is a presentation of information, not a complete map of its storage. One panel may combine a filename from disk, exposure information from the image, a rating from its database and a caption from a sidecar. Similar panels in two applications need not be reading the same authority.

Follow the information through its storage locations

Image filePixels or camera data, plus any embedded metadata

SidecarAssociated information beside the source file

CatalogReferences, relationships and application decisions

Delivered derivativeOnly the information the export actually includes

Embedded metadata lives inside the image container. A byte-for-byte copy carries those embedded bytes. A newly rendered export is different: the exporting program decides which information to copy, modify or omit. Changing a JPEG’s metadata also need not mean recompressing its image data; inspect the operation rather than inferring behavior from the extension.

A sidecar is an associated file, commonly with an .xmp extension. Keep it with its source and preserve the association when renaming or moving. Adobe’s Camera Raw settings documentation describes database, sidecar and embedded storage choices. These are Adobe-specific behaviors, not a promise that every application uses the same rules.

A catalog can hold relationships that do not fit into a simple caption field: this frame belongs to the original job, the editor shortlist and an album revision. Copying only the source image may leave those relationships behind. Conversely, copying only a catalog can preserve a reference while leaving its photograph on a disconnected drive. See catalogs, folders and collections for that data-model distinction.

For the example assignment, write a short storage note: originals in the job’s Originals folder; editor instructions in the named catalog and associated sidecars; approved outputs in Delivery; credit and caption checked in those outputs. A small explicit record is more useful than assuming a backup program knows which files belong together.

Build a small field plan that serves the job

Use fields for their defined purpose instead of putting every useful fact into one long keyword list. The IPTC specification distinguishes Creator, Description, Credit Line, Copyright Notice, Keywords and Date Created. The following example values are illustrative, not legal wording or a required studio template.

Creator

The photographer or creating organization, rather than automatically the client.

Description / Caption

Verified context: “Preparations for the evening ceremony at the garden venue.” Check names rather than guessing.

Credit Line

The agreed display credit, separate from the description.

Copyright Notice and usage information

The relevant notice and instructions. Retain the underlying agreement separately.

Keywords

Useful retrieval terms, such as ceremony, garden and evening, without redundant variants.

Date Created

The photograph’s creation context, distinct from a copy or delivery date.

Keep the initial plan modest. For a private family commission, your internal identification needs may differ from those for an editorial archive. Decide which fields belong in public derivatives and which sensitive notes should remain in protected job records. A private production note is not automatically a useful public caption.

Test one unusual value before applying a template widely. Use an accented name, an apostrophe, a compound keyword and a longer caption. Reopen the result in the intended recipient’s software. This is a practical way to expose encoding, truncation or display problems before they affect an entire assignment.

Make keywords, ratings and labels portable on purpose

Keywords describe content; ratings record an assessment; color labels often record a work stage. They can support one another without meaning the same thing. “Garden” can remain useful years later, while “needs second pass” describes today’s task. A three-star image may be technically usable but absent from a final delivery for narrative reasons.

The IPTC user guide recommends recording a consistent rating rationale and notes that rating meaning is not universal between collections. A five-star value can travel while the explanation behind it does not. Keep a readable key with any handoff where those distinctions matter.

Adobe’s XMP Basic namespace defines xmp:Rating with −1 for rejected, 0 for unrated and a range through 5. It defines xmp:Label as text. That is not a standardized cross-application rule saying red means reject or green means client-approved. A program’s displayed color may depend on its label definitions.

Consider a hypothetical handoff: the sender’s green label means “retouching still needed,” while the recipient uses green for “ready to print.” Even if a field transfers perfectly, the workflow can be wrong. Send the label key, or use a separately named selection whose meaning is explicit. Read the ratings and color-label workflow for the decision process rather than treating a color as an instruction on its own.

Hierarchical keywords add another question. A reader may display a tree, a flat set of terms or both. Test a small parent/child example rather than assuming identical hierarchy support. Do not use a search result as your only test: inspect the field values and the resulting retrieval in the receiving application.

Treat dates and location as information to verify

A copied file’s filesystem date can reflect a copy or modification event rather than the moment of exposure. A camera clock can be wrong. For a two-camera assignment, compare a known shared moment before changing thousands of timestamps. Preserve the original record and explain any correction; do not repair the sequence by replacing every date with the import day.

Record whether the source supplies a time offset or zone. If it does not, keep the uncertainty visible instead of inventing one. The current CIPA standards index lists Exif 3.1; older metadata explanations should not be treated as an exhaustive description of every modern date field. A visible local-time string alone cannot resolve a daylight-saving transition.

Location can be useful in an archive and inappropriate in a public derivative. Apple explains how shared location metadata can reveal where media was captured. Review the delivery copy for the actual distribution channel. A wedding venue, a private home and a sensitive location can call for different decisions.

Rights metadata also expresses information rather than enforcing it. Adobe’s XMP Rights namespace explicitly distinguishes rights-expression properties from DRM controls. Preserve useful attribution and agreements, but do not assume a copyright field prevents copying, survives every platform or settles a permissions dispute.

A seven-step metadata handoff test

1. Choose safe sample files. Use backed-up copies of a RAW, a JPEG and any format central to the job. Include an existing sidecar where relevant.
2. Record the starting state. Note filenames, locations, important field values and the application version. Keep the unmodified copies available.
3. Define the intended change. For example, add a verified credit and caption. Avoid a blanket template that replaces unrelated fields.
4. Check the write destination. Establish whether the command updates a catalog, sidecar or embedded metadata. If the application cannot say, investigate before batch use.
5. Close and reopen. Confirm that the values persist beyond the current panel. Check the exact selected subject, not only a neighboring image with a similar filename.
6. Produce the real delivery derivative. Use the intended export settings. Inspect the resulting file independently, including the desired credit and any location removal.
7. Test the receiving workflow. Open the packet where it will actually be used. Reconcile values, labels and associations, then retain the transfer notes with the job.

For the illustrative assignment, an acceptance note might say: “Caption and credit visible in both exported JPEGs; location intentionally omitted; original sources and sidecars retained; final image IDs recorded separately.” That states what was checked. It does not claim that every field in every format was tested.

A worked conflict: the venue name changed

Suppose the catalog still calls a venue “The Orchard,” a sidecar contains the corrected “Orchard House,” and the earlier client JPEG uses the original name. Do not begin by selecting every photograph and pressing a synchronization button. First confirm the correction against the job record. Identify which file is a previously delivered version and which record should drive future derivatives.

On a sample copy, make the intended working record consistent, export a newly named derivative and inspect its caption independently. Keep the earlier delivery identifiable instead of silently replacing it. Then document the correction and apply the tested route to the relevant photographs. If the receiving designer uses the older JPEG, send the corrected output with an explicit replacement instruction; a corrected catalog cannot update a file already on someone else’s computer.

This exercise separates factual authority, application authority and delivery state. The job record establishes the correct venue name. Your chosen writer establishes where future exports read it. The recipient’s actual file establishes what they can see. A metadata workflow needs all three, even when the visible correction is only one word.

Diagnose mismatches without overwriting the evidence

The caption appears in one application but not another

First determine where each program reads the value. One may be showing its catalog, another only embedded information. Check whether a sidecar is missing or a refresh is required, and inspect a disposable copy before choosing a command that overwrites either side. “Synchronize” deserves the same scrutiny as “save.”

The photo has two conflicting descriptions

Different metadata representations or an older catalog value can coexist. Identify the intended authority and retain the alternatives in your notes until the conflict is understood. Do not repeatedly round-trip the file between writers in the hope that the values will converge correctly.

The sidecar is present but the edits do not appear

Correct naming and location do not establish that the reader understands the stored processing instructions. XMP is a representation framework, not a universal image-rendering algorithm. Confirm the originating processor, version and settings support. Keep a reference derivative when visual intent matters.

The delivered image has fewer fields

Check the export’s metadata policy and the distribution service. Compare the saved file before upload with the downloaded result after upload. Keep the approved output if you need evidence of what left the studio. Do not overwrite the original to imitate a reduced public copy.

What Lightbox Pro currently preserves and exposes

In reviewed Lightbox Pro build 0.1.2 (60), local ratings, labels, filters and nested catalog sets support organization. Supported imported descriptions, repeated keywords and custom-field values are retained as read-only import information. Current search matches filenames. This does not establish native keyword authoring, general metadata search, editing every EXIF/IPTC property or XMP writeback to originals.

For supported original iView catalogs, distinguish preservation from interchange. A retained annotation is valuable even if it is not an editable native field; a converted rating is not proof that an external editor will see it in the source file. Read the verified .ivc import boundaries before planning that part of a migration.

Keep the metadata plan with the library, back up its associated records, and verify the actual handoff you depend on. The next useful step is understanding where editing decisions live, followed by moving the complete library to another Mac.