Does a photo show where it was taken?

EXIF is a TIFF file living inside the JPEG

A JPEG starts with the two bytes FF D8 and is then a run of marked segments: a FF byte, a marker byte, and for most markers a two-byte length. EXIF lives in the segment marked FF E1, the first APP1 segment. In the file built for this page it begins at byte 2, immediately after the two that open the file.

In a file built by hand for this page, that segment declares a length of 390 bytes. Its first six bytes are the ASCII letters Exif and two zero bytes. Everything after them is a complete TIFF file, header and all, wrapped inside the JPEG.

That is the part people do not expect. EXIF is not a list of labels bolted onto the picture. It is a TIFF image file directory riding in a JPEG segment, read with TIFF's rules:

• The TIFF header is eight bytes: two for byte order, II for little-endian or MM for big-endian, then the number 42 as a sanity check, then a four-byte offset to the first directory.
• Every offset inside the block is counted from that header, not from the start of the file.
• A directory is a two-byte entry count, then that many entries of exactly twelve bytes: two bytes of tag number, two of data type, four of count, and four that hold either the value itself or, when the value needs more than four bytes, an offset to where it is kept.
• Type 2 is ASCII, type 3 a 16-bit integer, type 4 a 32-bit integer, and type 5 a rational: two 32-bit integers, numerator then denominator, eight bytes in all.

Two tags are doors rather than data. Tag 0x8769 holds the offset of a second directory, the Exif IFD, and tag 0x8825 holds the offset of a third, the GPS IFD. The location is in that third one.

How a coordinate is actually written

The GPS directory in the test file has seven entries. Latitude is tag 0x0002, type 5, count 3: three rationals in a row, twenty-four bytes, meaning degrees, minutes and seconds. Read back, those twenty-four bytes are 43/1, 38/1 and 3312/100.

Nothing in those numbers says north or south. That is a separate tag, GPSLatitudeRef, number 0x0001, a two-character ASCII string short enough to fit in the entry's own four-byte slot. In the file those four bytes read 4E 00 00 00: the first two are the value, the letter N and a terminator, and the other two are padding.

Longitude is the same pair: GPSLongitude at 0x0004 as three rationals, and GPSLongitudeRef at 0x0003 holding E or W. GPSAltitude is 0x0006, a single rational, 765/10 in this file, with 0x0005 beside it saying whether that height is above or below sea level.

Both EXIF readers on this site were pointed at that file and both came back with 43.642533, -79.387333, which is the point it was built to describe, and an altitude rounded to 77 metres.

The resolution matters. The seconds in that file are stored in hundredths. One second of latitude is about 30.9 metres, so a hundredth of a second is about 31 centimetres. A photograph is not saying which neighbourhood it was taken in. It is saying which doorway.

The rest of what is in there

GPS is the tag people have heard of. It is not the only one that identifies a person.

• DateTimeOriginal, tag 0x9003, the moment the shutter fired, to the second. 0x9004 holds the time it was digitised.
• Make (0x010F) and Model (0x0110): the manufacturer and the exact body or handset.
• LensModel (0xA434), and on some makes LensSerialNumber (0xA435).
• Software (0x0131): the program and version that last wrote the file. A photograph that has been through an editor says so.
• Artist (0x013B) and CameraOwnerName (0xA430): a person's name, typed in once when the camera was set up and written into every frame since.
• BodySerialNumber, tag 0xA431. Not every make writes it, but where it is written it is the serial number of the camera body, and it is the same value in every photograph that body has ever taken. It links pictures that have nothing else in common to one physical camera, and through a warranty or a sale receipt to a person.

What removes it, and what does not

One mechanism answers all of it, and it is worth having instead of a list of apps. A file moves in one of two ways.

The bytes are copied. An email attachment, a file put in cloud storage, a chat app's send-as-file or send-as-document path. Nothing looks inside; the bytes that arrive are the bytes that left, EXIF included.

The picture is decoded and encoded again. The application reads the pixels, throws the container away and writes a new file. Nothing in the old container survives, because the new file was never built from it. When you press download on CLOAK, this is what happens: the image is drawn into a canvas, the canvas holds pixels and nothing else, and the JPEG written out of it has no APP1 segment at all.

Everything else follows from those two.

• A screenshot is the second kind by definition. It is a fresh encode of what was on the screen, so it carries none of the original file's metadata, and equally none of its proof of when the original was taken.
• Apps that resize your photo before sending it are doing the second kind, and the metadata goes with it. Which apps do that, on which upload path, and whether it changed in the last release, is documented by none of them. It is a behaviour to check, not to rely on.
• Sending the same photo as a file or document rather than as a photo is usually the first kind, and usually keeps everything. The point of that option is to deliver the file unchanged.
• Cropping is a trap. Most editors rewrite the picture data and copy the EXIF block across untouched, so a crop that removes a face from view does not remove the coordinates of where the face was standing.

Cropping has a second problem. EXIF can hold a small copy of the picture. The four bytes at the end of the first directory point at a second directory, IFD1, and tags 0x0201 and 0x0202 there give the offset and the length of a thumbnail JPEG stored inside the EXIF block. An editor that rewrites the main image and copies the block across carries the old thumbnail with it, which is how a cropped or spot-edited photograph can still contain a small picture of what was cropped out.

What to do about a photo you are about to send

Look first. The photo metadata checker reads the file in the browser tab and prints what is in it, with any coordinates linked through to a map so you see the spot rather than a pair of numbers. Nothing is uploaded, which you can confirm by turning the network off and using it anyway.

Then strip it. CLOAK re-encodes through a canvas, so what comes out has no EXIF, no XMP, no thumbnail and no maker note. On the same page you can black out or coarsely pixelate a region, and that happens to the pixel data before encoding, so there is no original layer underneath to recover.

If the problem is a face rather than the metadata, VEIL blurs faces, plates and names at full resolution in the same tab.

What this is, and what it is not

It reads JPEG. Other formats keep metadata elsewhere. CLOAK and the checker parse the APP1 segment of a JPEG. PNG carries EXIF in an eXIf chunk and WebP in an EXIF chunk, in a different place with a different structure. Given a file that is not a JPEG, CLOAK says so rather than guessing at it.

The embedded thumbnail is not listed. Neither reader here follows the pointer at the end of the first directory to IFD1, so a thumbnail in the EXIF block is not shown in the tag list. A file was built with one to check: the thumbnail's own FF D8 sits at byte 112 and neither reader mentions it. Stripping still removes it, because the output is built from pixels, but checking will not warn you it was there.

A clean file can still say where it was taken. Removing the metadata does not anonymise the picture. Street signs, shopfronts, a skyline, a window view, a reflection in a pair of glasses and the contents of a screen in frame all fix a location, and none of them are in the EXIF block.

Stripping by re-encoding costs a little quality. A JPEG written back out of a canvas is compressed again, at quality 0.92 here. It is a second generation of a lossy format. For anything where the pixels themselves are the evidence, keep the original somewhere safe and send the stripped copy.

Data can also sit after the end of the image. A JPEG ends at the two bytes FF D9. Anything after that is not part of the picture and no viewer will show it, but it is still in the file. STEGOSCAN measures that gap and reports what is in it.