Appreciating Exif | Brent Fitzgerald

I recently was writing some code to apply a mask to an image input. The mask had no Exif metadata, but the image did, so I had to adjust for the orientation of the image by reading it from Exif. This isn’t hard with libraries, and I knew the gist of the problem: images can have Exif, Exif is optional, phones and cameras use it for orientation, and you need to account for that when processing pixels directly. But I did not have a clear mental model of how Exif actually is represented in files. I was curious. I had questions: Where exactly is that orientation value stored? When should I rotate pixels instead of preserving a tag? What else might be hiding in the metadata? When is it typically stripped? So this is a little random walk guide to Exif. What is Exif? Exif is short for Exchangeable Image File Format. The current standard comes from CIPA, which lists it as “Exchangeable image file format for digital still cameras: Exif Version 3.1.”1 The Library of Congress has a good preservation-oriented summary, too. You’ll often see EXIF in all caps in camera docs, file-format chunk names, and old forum posts, but Exif seems to be the normal spelling in the standard itself. It is a metadata format that came out of the digital camera world in 1995, back when the problem was something like: this camera produced a JPEG, but where do we put the timestamp, shutter speed, aperture, focal length, thumbnail, and the fact that the camera was sideways? The answer was Exif. Most people run into this data through images from phones and cameras. It is also closely related to TIFF, because the actual Exif payload is a TIFF-shaped data structure living inside another file. Newer formats can carry Exif too, but each format gives it a different house.2 It’s optional. An image can have none. A camera image probably has some, but a processed image may have had it stripped. A synthetic image can have fake Exif because metadata is just data someone wrote into the file. Where it lives For JPEG, Exif usually lives near the beginning of the file in an APP1 marker segment. A JPEG starts with two bytes: FF D8 That is the start-of-image marker. After that, a JPEG is a series of marker segments.

Each segment starts with FF and a marker byte. APP1 is: FF E1 If that APP1 segment contains Exif, its payload starts with: 45 78 69 66 00 00 or, as text: Exif\0\0 Then comes the TIFF-based part. It starts with a byte order marker: II // Intel, little-endian MM // Motorola, big-endian Then the TIFF magic number, 42, then an offset to the first Image File Directory, usually called IFD0. An IFD is a list of entries. Each entry has a tag id, a type, a count, and either a value or an offset to the value. Exif orientation is tag 0x0112. It is usually in IFD0. Its value is a small integer from 1 to 8. That is the whole trick at a very high level. A tool looking for Exif in a JPEG:

walks the JPEG markers to find APP1, checks for Exif\0\0, reads the TIFF header, follows the IFD entries, and looks for the tags it cares about.

So the “where is Exif?” depends on the file. In JPEG, it is usually APP1. In WebP, it is an EXIF chunk. In HEIC, it is inside the HEIF box structure. If you want a lovely older walkthrough of the JPEG layout, the MIT Media Lab’s Deep View project has one. A boring standard that aged well I have a soft spot for simple standards that just keep working. Exif is not clean in the way you might design something from scratch today. It has TIFF internals. It has manufacturer MakerNotes. It has duplicate concepts across Exif, XMP, IPTC, ICC profiles, C2PA, and container metadata. The orientation tag feels simple until you try to explain values 5 and 7. It has continued to solve a real problem, though: pixels are not enough. A camera needs somewhere to put the circumstances of the image, and it’s simpler for everyone if that data is bundled into the image rather than shipped around as an accompanying file. I admire it because it grew out of its initial container. In JPEG, Exif usually sits in APP1.

In newer file formats like HEIC, it lives somewhere else. But the same payload format still applies. A phone in 2026 can take a photo in a modern container and still carry metadata shaped by decisions from the digital camera era. What Exif is used for The common stuff is what you would expect from a camera:

date and time camera make and model lens model shutter speed aperture ISO focal length flash GPS location orientation software color-space hints manufacturer-specific MakerNotes

Thumbnails are a “maybe”: Exif can carry an embedded thumbnail, usually in IFD1.3 It commonly is a small embedded thumbnail. Larger previews are messier. Some are Exif thumbnails, some are MakerNotes, some are MPF data, and some live in container-specific metadata. This is not everything. It is the usual useful slice. Photo apps use this data to sort, search, display, group, and edit images. Websites and upload pipelines use it, sometimes accidentally, to rotate images correctly. Photographers use it to inspect how a shot was made. Asset-management systems use it alongside other metadata standards for rights, captions, credits, and workflow state. Color is a good example of boundaries blurring. Exif has a ColorSpace tag, but full ICC color profiles are a separate kind of metadata.4 If an image changed size, rotated, lost its color, or started displaying differently after a pipeline step, metadata is one of the first places I would look, but I would not assume the answer is specifically Exif. And of course, metadata is just whatever was put in the file. A file can say it came from a camera it did not come from.

Orientation is in IFD0. Exposure details are in ExifIFD. Apple-specific camera data is in Apple. The thumbnail is in IFD1. The color profile is not Exif at all. And yes, GPS can be right there in the file. -a shows duplicate tags. -G1 shows the family/group. -s uses short tag names. This matters because “the orientation” or “the date” may exist in more than one place. For orientation specifically: exiftool -Orientation image.jpg exiftool -Orientation# image.jpg The first gives the friendly value: Orientation : Rotate 90 CW The second gives the raw integer: Orientation : 6 To strip metadata: exiftool -all= image.jpg By default, exiftool writes a backup file ending in _original. This is slightly annoying when the files clutter your directory, but charming once you remember that it is politely not overwriting. If you do not want the backup: exiftool -overwrite_original -all= image.jpg Orientation Orientation is what I typically encounter with Exif. Cameras and phones do not typically rotate the pixel matrix when you turn the device. They save the pixels in a native orientation and write an Exif tag that tells viewers how to display those pixels. Most image viewers respect the tag. Some image-processing tools expose the raw pixels first. Some preserve the tag, others clear the tag. All of these behaviors are defensible in some situations. Depends on the context. Here are the eight Exif orientation values. These are JPEGs generated for this post. They all start from the same 160×160 base image data, then get a different Exif orientation value written with exiftool.

Value Image Exif meaning Display correction 1 top-left normal 2 top-right mirror horizontal 3 bottom-right rotate 180° 4 bottom-left mirror vertical