Appreciating Exif

# Appreciating Exif | Brent Fitzgerald Source: [https://brentfitzgerald.com/posts/appreciating-exif/](https://brentfitzgerald.com/posts/appreciating-exif/) 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](https://www.cipa.jp/e/std/std-sec.html), which lists it as “Exchangeable image file format for digital still cameras: Exif Version 3\.1\.”[1](https://brentfitzgerald.com/posts/appreciating-exif/#user-content-fn-cipa-pdf)The[Library of Congress has a good preservation\-oriented summary](https://www.loc.gov/preservation/digital/formats/fdd/fdd000618.shtml), 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](https://brentfitzgerald.com/posts/appreciating-exif/#user-content-fn-containers) 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](https://www.media.mit.edu/pia/Research/deepview/exif.html)\. ## 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](https://brentfitzgerald.com/posts/appreciating-exif/#user-content-fn-ifd1)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](https://www.color.org/specification/ICC.1-2022-05.pdf)are a separate kind of metadata\.[4](https://brentfitzgerald.com/posts/appreciating-exif/#user-content-fn-icc)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\. Timestamp can be wrong, GPS can be fake, a string field can contain gobblygook\. If you are doing anything technical with image metadata, start with[`exiftool`](https://exiftool.org/)\. It is Perl and is old in the very good way\. It has baked into it all sorts of knowledge about metadata weirdnesses that exist in real files\. The basic command is: ``` exiftool image.jpg ``` Here is the top of a real iPhone JPEG: ``` ExifTool Version Number : 13.55 File Name : image.jpg Directory : /tmp File Size : 3.6 MB File Type : JPEG File Type Extension : jpg MIME Type : image/jpeg JFIF Version : 1.01 Exif Byte Order : Big-endian (Motorola, MM) Make : Apple Camera Model Name : iPhone 13 Orientation : Rotate 90 CW X Resolution : 72 Y Resolution : 72 Resolution Unit : inches Software : 26.3.1 Modify Date : 2026:04:21 20:05:42 Host Computer : iPhone 13 Exposure Time : 1/317 F Number : 1.6 Exposure Program : Program AE ISO : 50 Exif Version : 0232 Date/Time Original : 2026:04:21 20:05:42 Create Date : 2026:04:21 20:05:42 ``` And that is just the start\. The full output keeps going: MakerNotes, GPS, an embedded thumbnail, MPF data, and an ICC profile\. For debugging, it’s nice to have groups and raw\-ish tag names: ``` exiftool -a -G1 -s image.jpg ``` An excerpt from the same file looks like this: ``` [File] ExifByteOrder : Big-endian (Motorola, MM) [File] ImageWidth : 4032 [File] ImageHeight : 3024 [JFIF] XResolution : 300 [JFIF] YResolution : 300 [IFD0] Make : Apple [IFD0] Model : iPhone 13 [IFD0] Orientation : Rotate 90 CW [IFD0] XResolution : 72 [IFD0] YResolution : 72 [ExifIFD] ExposureTime : 1/317 [ExifIFD] FNumber : 1.6 [ExifIFD] ISO : 50 [ExifIFD] DateTimeOriginal : 2026:04:21 20:05:42 [ExifIFD] FocalLength : 5.1 mm [ExifIFD] LensModel : iPhone 13 back dual wide camera 5.1mm f/1.6 [Apple] MakerNoteVersion : 16 [Apple] AccelerationVector : -0.0088618109 -0.1003010348 -1.003354311 [GPS] GPSLatitude : [redacted, because this is the internet] [GPS] GPSLongitude : [redacted, same reason] [GPS] GPSHPositioningError : 20.61573126 m [IFD1] ThumbnailLength : 6400 [MPF0] NumberOfImages : 2 [ICC_Profile] ProfileDescription : Display P3 ``` This is why I like the grouped view\.`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`\. ValueImageExif meaningDisplay correction1top\-leftnormal2top\-rightmirror horizontal3bottom\-rightrotate 180°4bottom\-leftmirror vertical5left\-toptranspose6right\-toprotate 90° CW7right\-bottomtransverse8left\-bottomrotate 270° CW / 90° CCWIf your browser respects Exif orientation, those should display differently\. If you right\-click and save them, you can inspect the raw tags yourself: ``` exiftool -Orientation -Orientation# orientation-6.jpg ``` The files were made roughly like this: ``` cp base.jpg orientation-6.jpg exiftool -overwrite_original -Orientation#=6 orientation-6.jpg ``` As a developer, if you are doing spatial transformations, it’s simplest if you normalize the orientation before touching pixels\. After that, set orientation to 1 or remove the tag\. Otherwise, some later viewer may helpfully rotate your already\-rotated image again\. For example, if you were using Python \+ PIL, you could call[`ImageOps\.exif\_transpose\(img\)`](https://pillow.readthedocs.io/en/stable/reference/ImageOps.html#PIL.ImageOps.exif_transpose)\. In JavaScript/TypeScript with Sharp, calling[`\.rotate\(\)`with no angle](https://sharp.pixelplumbing.com/api-operation/#rotate)auto\-orients based on Exif orientation\. In other stacks the method name may be`autorotate`,`autoOrient`, or a flag on decode\. The name matters less than knowing whether the pixels you are working with are raw or display\-oriented\. ## Dumb Exif tricks If you’re an[LLM obsessed with goblins](https://openai.com/index/where-the-goblins-came-from/), you can put a goblin in the artist field: ``` exiftool -Artist='a small goblin' image.jpg ``` You can put GPS coordinates on a totally synthetic image: ``` exiftool \ -GPSLatitude=37.7749 -GPSLatitudeRef=N \ -GPSLongitude=122.4194 -GPSLongitudeRef=W \ image.jpg ``` You can make an image claim to come from whatever camera you want: ``` exiftool -Make='Definitely A Camera' -Model='Trust Me 9000' image.jpg ``` This is funny, but it is also the point\. Metadata is not a sworn affidavit\. It is input\. Sometimes useful input\. Sometimes private input\. Sometimes nonsense input\. Exif is only one part of the image metadata pile\. There is[XMP](https://developer.adobe.com/xmp/docs/XMPSpecifications/), which is the RDF/XML\-style format used by Adobe and a lot of asset workflows\. It can carry edits, ratings, rights, captions, application state, and custom namespaces\. There is[IPTC Photo Metadata](https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata), which comes from news and photojournalism workflows: captions, credits, copyright, keywords, location, and editorial fields\. There are ICC profiles, which are not Exif but matter a lot if you care about color\. If you have ever had an image look washed out or weirdly saturated after conversion, color profiles may have been involved\. There is also[C2PA](https://c2pa.org/specifications/specifications/), the Content Credentials/provenance world\. C2PA is for signed claims about where a piece of media came from and what happened to it\. It can include assertions, thumbnails, ingredients, hashes, and signatures\.[OpenAI describes using C2PA metadata for generated images](https://openai.com/index/advancing-content-provenance/), and other image\-generation and creative tools are moving in the same direction\. C2PA is not Exif\. It is image metadata, but it is not the old TIFF\-shaped Exif payload in APP1\.[5](https://brentfitzgerald.com/posts/appreciating-exif/#user-content-fn-c2pa-location) There are also structures specific to image formats\. JPEGs can have`JFIF`metadata\. PNGs have chunks like`tEXt`,`iTXt`,`zTXt`,`eXIf`, and`iCCP`\. HEIF, AVIF, and WebP have their own container structures\. Cameras write MakerNotes, which are manufacturer\-specific and often proprietary\. Files can contain embedded thumbnails or previews, and those thumbnails do not have to match the main image forever\. So yes, there are many other things in the image file besides Exif\. “Stripping Exif” is not the same as “removing everything that isn’t pixels\.” There can be all sorts of other things in there, and that’s not even counting[encoding data in the image itself with Fourier transforms](https://backdrifting.net/post/022_fourier_steganography)\. ## Uploads and stripping Do not assume the operating system strips Exif, or any other metadata, when you upload an image\. The actual behavior depends on the source image, OS, browser, file picker, app, export path, transformation pipeline, and receiving service\. The useful rule is boring: > Expect that images you upload or receive may contain metadata unless you explicitly stripped it or inspected the actual resulting file\. That is true in both directions\. If you are accepting uploads, do not assume the user’s metadata is gone\. If you are sending images somewhere else, do not assume your local privacy\-sensitive metadata will be removed for you\. ## Libraries and approaches I would think about metadata libraries in three buckets\. 1. Wrap[`exiftool`](https://exiftool.org/)\. This is the “I need the tool with all the esoteric knowledge” option\. It is often the right choice for inspection or forensic\-ish debugging\. But you are shelling out to a Perl program, so you have deployment and performance questions\. 2. Use native libraries or image\-processing stacks\. That includes C libraries like[`libexif`](https://libexif.github.io/), and image libraries like[ImageMagick](https://imagemagick.org/)or[libvips](https://www.libvips.org/)\. A lot of Node and TypeScript developers meet libvips through[Sharp](https://sharp.pixelplumbing.com/)\. This bucket is what you want when the real job is image processing: autorotate, resize, convert, strip or preserve metadata, write the result\. It is not necessarily the same as a comprehensive metadata\-inspection tool\. 3. Parse metadata yourself\. This can be perfectly reasonable if the task is small and you’re okay without covering absolutely every case\. “Read Exif orientation from JPEG APP1” is small\. “Correctly support Exif, MakerNotes, XMP, IPTC, ICC profiles, C2PA, JPEG, PNG, WebP, HEIC, AVIF, malformed files, and a weird camera someone bought in 2009” is not\. A few starting points: - JavaScript/TypeScript:[`exifr`](https://github.com/MikeKovarik/exifr),[`ExifReader`](https://github.com/mattiasw/ExifReader),[`piexifjs`](https://github.com/hMatoba/piexifjs), and[Sharp](https://sharp.pixelplumbing.com/)for image processing\. - Go:[`barasher/go\-exiftool`](https://github.com/barasher/go-exiftool),[`dsoprea/go\-exif`](https://github.com/dsoprea/go-exif), and[`rwcarlsen/goexif`](https://github.com/rwcarlsen/goexif), which is popular but quiet these days\. - Python:[Pillow](https://pillow.readthedocs.io/)for basic Exif access and image operations,[`exifread`](https://github.com/ianare/exif-py)for reading,[`piexif`](https://piexif.readthedocs.io/)for editing JPEG Exif, and[`PyExifTool`](https://github.com/sylikc/pyexiftool)if you want an`exiftool`wrapper\. Some of these libraries are not especially active\. That is not automatically disqualifying, because Exif is pretty fixed at this point\. Maintenance matters more if you need newer file formats, security fixes, malformed\-file handling, or broad tag coverage\. ## My rules of thumb If you process pixels, normalize orientation first\. If you publish or store user images and want to preserve privacy, strip metadata intentionally\. If you parse metadata, treat it as untrusted input\. If you only need one tag, you can maybe parse one tag\. If you need all the things, use a tool that has spent decades learning all the things\. ## Please proceed to the exif So there you have it\. If you made it this far, your interest in image metadata exceeds that of most normal people\. And if I missed something important, or if you have more stupid Exif tricks you’ve seen in the wild, please drop me a note\. --- 1. I could not find a stable direct PDF URL, but CIPA’s download endpoint is here:[CIPA DC\-008\-Translation\-2026](https://www.cipa.jp/std/documents/download_e.html?CIPA_DC-008-2026-E)\. The PDF itself includes a copyright notice and sits behind CIPA’s disclaimer\.[↩](https://brentfitzgerald.com/posts/appreciating-exif/#user-content-fnref-cipa-pdf) 2. WebP has an[`EXIF`chunk](https://developers.google.com/speed/webp/docs/riff_container#metadata)\. HEIC/HEIF and AVIF can carry Exif metadata as metadata items in their own container structures\. PNG has always had a chunk\-based metadata story, and modern PNG also has an[`eXIf`chunk](https://www.w3.org/TR/png-3/#11eXIf), but PNG is not the classic Exif habitat\.[↩](https://brentfitzgerald.com/posts/appreciating-exif/#user-content-fnref-containers) 3. Image File Directory, the TIFF\-ish table of tag entries inside Exif\. IFD0 usually describes the main image; IFD1 is the next directory\.[↩](https://brentfitzgerald.com/posts/appreciating-exif/#user-content-fnref-ifd1) 4. In JPEG, an ICC profile is normally stored in`APP2`, not inside Exif\. In PNG, it can be in`iCCP`\.[↩](https://brentfitzgerald.com/posts/appreciating-exif/#user-content-fnref-icc) 5. In JPEG, the C2PA manifest store is serialized as JUMBF and embedded in`APP11`marker segments\. In PNG, the spec uses a`caBX`chunk\. In BMFF\-ish formats, it lives in boxes\.[↩](https://brentfitzgerald.com/posts/appreciating-exif/#user-content-fnref-c2pa-location)