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. Timestamp can be wrong, GPS can be fake, a string field can contain gobblygook.

Use exiftool first

If you are doing anything technical with image metadata, start with exiftool.

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.

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
5		left-top	transpose
6		right-top	rotate 90° CW
7		right-bottom	transverse
8		left-bottom	rotate 270° CW / 90° CCW

If 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). In JavaScript/TypeScript with Sharp, calling .rotate() with no angle 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, 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, 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, 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, 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, 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

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.

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. 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, and image libraries like ImageMagick or libvips. A lot of Node and TypeScript developers meet libvips through Sharp.

   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, ExifReader, piexifjs, and Sharp for image processing.
• Go: barasher/go-exiftool, dsoprea/go-exif, and rwcarlsen/goexif, which is popular but quiet these days.
• Python: Pillow for basic Exif access and image operations, exifread for reading, piexif for editing JPEG Exif, and 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.

---

Footnotes

1. I could not find a stable direct PDF URL, but CIPA’s download endpoint is here: CIPA DC-008-Translation-2026. The PDF itself includes a copyright notice and sits behind CIPA’s disclaimer. ↩

2. WebP has an EXIF chunk. 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, but PNG is not the classic Exif habitat. ↩

3. Image File Directory, the TIFF-ish table of tag entries inside Exif. IFD0 usually describes the main image; IFD1 is the next directory. ↩

4. In JPEG, an ICC profile is normally stored in APP2, not inside Exif. In PNG, it can be in iCCP. ↩

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. ↩