Image Metadata & EXIF Data Research

What is Image Metadata?

Image metadata is embedded information stored inside an image file alongside the pixel data itself. This data is written at capture time by the camera or device, and can be extended later by editing software, photo management tools, or publishing systems. The three primary standards — EXIF, IPTC, and XMP — each serve a different purpose and are often all present in the same file simultaneously.

EXIF (Exchangeable Image File Format) is a binary format embedded in the JPEG or TIFF header at capture time. It answers "how and when was this taken?" — camera model, lens, shutter speed, aperture, ISO, GPS coordinates, and timestamps. IPTC answers "what is this a photo of and who owns it?" — captions, keywords, copyright, and location names. XMP is Adobe's XML-based format that answers "what has been done to this file?" — edit history, star ratings, colour labels, and Lightroom adjustments. Understanding which standard holds which data is essential before using any metadata extraction tool.

Beyond these three, every image file carries an ICC color profile block describing how its colors should be displayed, and most JPEGs contain an embedded thumbnail — a complete tiny JPEG stored inside the file that your OS file browser shows before decoding the full image. File-level metadata (size, format, filesystem timestamps) rounds out the picture, though it's the least reliable layer. For most practical purposes, EXIF + GPS + IPTC covers the vast majority of real-world use cases.

GPS & Geolocation Fields

GPS metadata is stored inside EXIF within a dedicated GPS IFD (Image File Directory). The most critical fields are the four core ones — GPSLatitude, GPSLatitudeRef, GPSLongitude, and GPSLongitudeRef. Without all four together you cannot place the photo on a map. Coordinates are stored as rational numbers in DMS format (Degrees, Minutes, Seconds), which must be converted to decimal degrees for use with mapping APIs.

The DMS to decimal conversion formula is: decimal = degrees + (minutes / 60) + (seconds / 3600), then apply a negative value if the reference is S (South) or W (West). The raw values in the file look like rational fractions (25/1, 46/1, 3456/100) — your parser needs to evaluate those before applying the formula.

GPSImgDirection is more common than people expect — modern iPhones and Android phones write this consistently. It tells you which way the camera was pointing when the shot was taken, which is useful for mapping and augmented reality applications.

GPSDOP (Dilution of Precision) is useful if you need to assess GPS accuracy. A DOP under 2 is excellent, 2–5 is good, above 10 is poor. GPSProcessingMethod reveals how the location was determined — GPS means actual satellite fix, CELLID means cell tower triangulation, WLAN means Wi-Fi positioning. This matters a lot for accuracy — a cell tower fix could be off by a kilometre or more. The GPSStatus field indicates whether the measurement was active (A) or void/invalid (V) at capture time.

Camera & Technical Fields

EXIF camera fields record the full shooting context. For display purposes the most useful set is: Make, Model, LensModel, FNumber, ExposureTime, ISOSpeedRatings, FocalLengthIn35mmFilm, Flash, and ExposureProgram. Note that FocalLengthIn35mmFilm is more meaningful to most users than the raw FocalLength value, because it gives a universally understood equivalent regardless of sensor size — "24mm equivalent" means something; "6.77mm" does not.

FNumber vs ApertureValue — both describe the aperture, but FNumber is the one you actually display (e.g. f/1.8). ApertureValue is stored in APEX units (a logarithmic scale) and needs a formula to convert: f-number = √(2^ApertureValue). Always read FNumber for display purposes.

Flash is a bitmask, not a simple yes/no. Bit 0 tells you if it fired, bits 3–4 give the mode (auto, forced, suppressed), and bit 5 indicates red-eye reduction was on. Most parsers decode this into a human-readable string automatically.

CustomRendered is a useful signal for detecting computational photography — portrait mode, Night mode, and HDR all set this to 1. Worth surfacing in a guide about phone photo metadata.

MakerNote is a goldmine and a minefield. It's a private binary block that each manufacturer fills with their own fields — Apple stores things like burst photo index, lens correction data, and face detection results in there. Canon stores lens correction matrices. Libraries like exifr (JavaScript) and piexifjs can decode some vendor MakerNotes, but coverage varies.

The practical display set — if you're building a photo info panel, the fields your users will actually care about are: Make, Model, LensModel, FNumber, ExposureTime, ISOSpeedRatings, FocalLengthIn35mmFilm, Flash, and ExposureProgram. Everything else is for power users or specific use cases.

Technical Image Properties

Dimensions vs. resolution — PixelXDimension and PixelYDimension are the actual pixel count of the image. XResolution / YResolution are just a hint about print size and are almost always 72 regardless of true quality. Don't use DPI to judge image quality — use pixel count.

The Orientation field is critical and frequently mishandled. A photo taken in portrait mode on a phone is often stored as a landscape image with Orientation: 6 (rotate 90° clockwise). Many apps fail to respect this tag, which is why photos sometimes appear sideways. Any image viewer or processor must read and apply this field.

ColorSpace vs. ICC profile — the EXIF ColorSpace tag is very blunt (just sRGB or uncalibrated). The embedded ICC profile in the file binary gives you the full story — Display P3, AdobeRGB, ProPhoto, etc. For a proper color-aware app you need to read the ICC profile, not just the EXIF tag. PhotometricInterpretation tells you the color model — most photos are YCbCr (6) because that's how JPEG stores color internally, even though it looks like RGB on screen. RAW/TIFF files are more often true RGB (2).

BitsPerSample — consumer photos are almost always 8, 8, 8 (24-bit color). RAW files and HDR images will show 16, 16, 16 or higher. This matters if you're building any image processing pipeline.

Date, Time & Timestamps

EXIF contains multiple timestamp fields and the differences between them matter enormously. DateTimeOriginal is the only one written at the moment of capture and never updated by editing software — always use this for "when was this taken." The plain DateTime field is overwritten every time an app touches the file, so a photo from 2018 edited in Lightroom last week will show last week's date there.

The timezone problem is a significant gotcha: EXIF timestamps have no timezone. The value 2024:07:04 14:32:10 is a local clock reading with no indication of where "local" is. OffsetTimeOriginal was only added in EXIF 2.31 (2016), so older photos and many Android devices still don't write it. The best fallback is to cross-reference GPSTimeStamp (which is always UTC, hardware-synced to satellite time) with DateTimeOriginal to calculate the offset.

Sub-second fields are worth reading if you're doing burst photo sorting or trying to distinguish photos taken in rapid succession. Modern iPhones write millisecond precision in SubSecTimeOriginal. GPS timestamps are hardware-synced to satellite time, making them the most accurate timestamps in the file — often more accurate than the camera's own clock, which can drift. The catch is they're always UTC.

Format quirk — EXIF uses colons in the date (2024:07:04) instead of the standard ISO dashes (2024-07-04). Most parsers handle this automatically, but if you're writing your own parser it will trip you up.

Recommended priority order when reading "time taken":

XMP Metadata

XMP (Extensible Metadata Platform) is Adobe's XML-based format embedded in the JPEG APP1 segment or stored as a sidecar .xmp file alongside RAW images. It records workflow data that EXIF was never designed to hold: star ratings, colour labels, edit history, keywords, and the specific software version that last touched the file.

Since it's plain XML, you can literally read XMP in a text editor. A real-world example from a Lightroom-edited photo:

dc: (Dublin Core) is the open standard for descriptive metadata — title, creator, rights, subject keywords. Stock photo sites and CMS platforms read this for cataloguing.

xmp: (Basic) holds workflow data — star rating (1–5), color label, the tool that created the file, and when the metadata itself was last modified.

xmpMM: (Media Management) is the edit history log. Every time Lightroom or Photoshop saves the file, it appends an entry. This gives you a full audit trail of what was done to an image.

photoshop: mirrors some IPTC fields — headline, credit, source, city, country, urgency rating. Widely used in news and stock photo workflows.

exif: and tiff: are XMP duplicates of EXIF tags. Some tools write both; others only write one. When they disagree, EXIF binary values are generally considered more authoritative.

The sidecar file pattern is worth explaining in detail. Lightroom by default never writes metadata back into RAW files — instead it creates a .xmp file sitting next to the image with the same name:

This is non-destructive editing — the original is never modified. The downside is if you move the image without the sidecar, all your edits disappear.

Reading XMP in code:

One key gotcha — XMP and EXIF can hold duplicate and sometimes conflicting data. DateTimeOriginal exists in both. GPSLatitude exists in both. The general convention: prefer EXIF binary for capture data (dates, GPS, camera settings), prefer XMP for workflow data (ratings, keywords, edit history). Never silently drop one without checking the other.

IPTC Metadata

IPTC (International Press Telecommunications Council) is the journalism and publishing industry's standard for describing the content of an image rather than how it was captured. While EXIF answers "how and when was this shot?", IPTC answers "what is this a photo of, who took it, and what are the usage rights?"

IPTC vs EXIF location fields — this is a common source of confusion. EXIF GPS gives you precise decimal coordinates you can drop on a map. IPTC location fields (City, Country, Sublocation) are free-text, human-curated strings written by a photo editor. They often disagree — a photographer shooting in Miami Beach might GPS-tag the exact street corner, but a photo desk editor writes "Miami" in the IPTC City field. For mapping, always use EXIF GPS. For display and search, IPTC text is more reader-friendly.

The Caption field is the most important one for content-managed systems. Getty, AP, Reuters, and most stock photo platforms populate this as the primary editorial description. If you're building any kind of media library or CMS integration, this is the field editors will rely on most.

Keywords is repeatable — unlike most EXIF fields which hold a single value, IPTC Keywords stores an array. Each keyword is a separate record 2:025 entry. Parsers return this as an array, not a comma-separated string, so handle it accordingly.

Special Instructions is underused but valuable — it's where rights restrictions, usage embargo notes, and editorial warnings live. News organisations use it to flag things like "minor depicted, do not publish without consent" or "embargoed until 00:01 EST". Worth surfacing in any professional media tool.

IPTC vs IPTC-IIM vs IPTC Core — the original binary format stored in images is technically IPTC-IIM (Information Interchange Model), written into the JPEG APP13 segment. "IPTC Core" refers to the newer XMP-based equivalent (photoshop: and Iptc4xmpCore: namespaces). Most modern tools write both simultaneously so older software can still read the binary version. When they conflict, IPTC Core / XMP is considered more authoritative.

The practical set for most use cases — if you're building a photo upload tool, media library, or CMS integration, the fields you actually need to read and write are: Headline, Caption, Keywords, By-line, Credit, Copyright Notice, City, Country Name, and Special Instructions. Everything else is specialist territory for wire services and news organisations.

Reading IPTC in code:

ICC Color Profiles

An ICC color profile is a standardised data block embedded in an image file that describes exactly how the colors in that file should be interpreted and displayed. Without one, a color like RGB(255, 128, 0) is ambiguous — it means different shades of orange on different screens. The profile pins it to a specific, absolute color in the real world.

Profile Connection Space (PCS) is the key concept. The ICC system works by converting colors from the source profile → a universal reference space (CIELAB or CIEXYZ, which map to how human eyes actually perceive color) → the destination profile. This two-step translation means any two profiles can talk to each other without needing a direct conversion for every possible pair.

The four profiles you'll encounter in practice:

• sRGB is the safe default — virtually every browser, OS, and consumer screen assumes sRGB when no profile is present. If you're building anything web-facing, you want images in sRGB.
• Display P3 is now the default on every iPhone, Mac, and iPad since around 2016–2017. If you display a P3 image in a browser without color management, the wider-gamut colors get clipped to sRGB and look washed out. Modern browsers and the CSS color() function handle P3, but it's worth flagging in any guide.
• Adobe RGB is for print workflows — it covers a wider range of greens and cyans that CMYK printers can reproduce but sRGB can't describe. You'll see it in photos from DSLRs set to a professional color mode.
• ProPhoto RGB is so wide it actually includes colors humans can't see. It's used in RAW editing software (Lightroom, Capture One) to avoid clipping during editing. Never serve a ProPhoto image on the web — it will look completely desaturated on any uncalibrated viewer.

The ICC block embedded in the image includes the profile name and description (e.g. "Display P3"), the RGB primary chromaticities, the white point (usually D65, standard daylight), tone response curves (the gamma curve per channel), and the rendering intent — which controls how out-of-gamut colors are handled when converting between profiles (perceptual shifts everything to fit, relative colorimetric clips).

The key practical warning — if you strip the ICC profile when processing or resaving an image (which many server-side tools do by default), the colors become ambiguous. A viewer will assume sRGB, and a P3 or Adobe RGB image will look subtly wrong — more saturated than intended or slightly off in hue. Always explicitly preserve or convert to sRGB when stripping profiles.

How to extract the ICC profile in code:

Embedded Thumbnails

Almost every JPEG shot on a digital camera or smartphone has a small preview JPEG baked right inside the file. The thumbnail is a complete, self-contained JPEG image stored inside the APP1 (EXIF) segment of the outer JPEG file. IFD1 holds two key pointers — ThumbnailOffset (where in the file the thumbnail bytes begin) and ThumbnailLength (how many bytes it spans). To extract it you just slice those bytes out and you have a valid JPEG you can decode or display independently.

Typical specs of the embedded thumbnail:

Why it matters in practice:

• Fast previews — load the thumbnail instantly instead of decoding a 12 MB full-res image just to show a grid view
• Server-side pipelines — when users upload photos, you can extract the thumbnail to show a preview before the full upload finishes
• Offline / low-bandwidth situations — serve the thumbnail for list views, only load full-res on demand

The orientation trap — the thumbnail is sometimes rendered at a different rotation than the main image, and its own Orientation tag can disagree with IFD0's. Always read and apply the thumbnail's orientation separately from the main image's orientation.

One gotcha — some images have a thumbnail that is outdated relative to the main image. If someone crops or heavily edits a JPEG in software that only updates the main image data but not the embedded thumbnail, the thumbnail will still show the original unedited version. This can actually be useful for forensics, but surprising for end users.

Extracting it in JavaScript using exifr:

Extracting it in Python using Pillow:

File Format & Metadata Support

JPEG and TIFF are the undisputed winners for metadata richness. TIFF technically edges ahead because it's lossless and natively structured around IFD (Image File Directory) — the same binary structure EXIF was derived from. But JPEG is the practical winner because universal tooling support means nothing strips or corrupts its metadata unexpectedly.

Three tiers worth knowing:

• The full-metadata tier — JPEG, TIFF, HEIC, and DNG — supports every metadata standard simultaneously, embedded in a single file. If someone asks what format to use for archiving photos with complete metadata intact, these are the answer.
• The web format tier — PNG, WebP, and AVIF — supports color profiles and XMP, but IPTC is either unsupported or ignored, and EXIF support is inconsistent across tools. PNG is the biggest gotcha here: the spec technically allows EXIF in a chunk, but server-side image processors (ImageMagick, Sharp, Squoosh) routinely strip it on export. Never rely on PNG preserving EXIF through a processing pipeline.
• GIF has no metadata support whatsoever — not even a color profile field.

The RAW caveat — vendor RAW formats (Canon's CR3, Nikon's NEF, Sony's ARW) embed EXIF deeply and preserve it reliably, but XMP edits from Lightroom live in a sidecar .xmp file rather than inside the RAW. DNG, Adobe's open RAW format, solves this by embedding XMP directly — which is why many archivists convert proprietary RAW files to DNG.

The pipeline stripping problem is probably the most practical thing to understand. Every time an image passes through a processing step, metadata is at risk:

To preserve metadata through a Sharp pipeline in Node.js:

Without .withMetadata(), Sharp strips everything by default. ImageMagick requires -strip to remove metadata and omitting it keeps it — the opposite default, which trips people up when switching tools.

HEIC deserves a special mention since it's now the default on every iPhone. It carries the full metadata suite and can store multiple images in one file (Live Photos, burst sequences), each with their own EXIF block. The catch is that browser support is still limited, so most web pipelines convert HEIC to JPEG on upload, and that conversion needs to explicitly carry metadata across.

Reference Data

The tables below provide a complete field-level reference for each metadata standard covered in this article.