What this tool does
Every photo from a modern phone or camera carries a block of metadata: where it was taken, on what, at what shutter speed, and often a serial number. Most viewers load ExifTool compiled to WebAssembly, which is a multi-megabyte download to read a few hundred bytes. This one is a hand-written parser over a DataView, small enough to ship in the page, and it tells you when a file has no EXIF at all instead of calling that a failure.
How it works
A JPEG keeps its metadata in a marker segment: the parser walks the 0xFF-prefixed segments looking for APP1, and the six bytes Exif\0\0 that introduce the real content. That leads to a TIFF header, whose first two bytes are the byte-order flag, II for little-endian or MM for big-endian, followed by the magic number 42 and a pointer to IFD0. IFD0 holds the ordinary tags, and two pointers inside it lead to the Exif sub-IFD and the GPS sub-IFD.
Each directory entry is 12 bytes, and the four bytes after the count are either the value itself or a pointer to it. The rule that trips up hand-written parsers is that anything wider than four bytes is an offset from the start of the TIFF header, not the value. Every entry is then decoded according to the type the file itself declares, which is what makes rationals come out as the fraction the camera stored rather than a rounded decimal: 1/125 s is stored as the pair 1 and 125, and the value 0.008 on its own has thrown the shutter speed away.
The hemisphere of a GPS coordinate comes from the reference letter, never from the sign of the number. A southern latitude is stored as a positive value plus an S, so inferring the hemisphere from the sign drops Sydney into the northern hemisphere — a real bug that has shipped in commercial viewers. This parser reads GPSLatitudeRef and GPSLongitudeRef explicitly, converts degrees, minutes and seconds to decimal degrees itself, and warns when the minutes or seconds fall outside their valid ranges.
The privacy answer is not whether a file has EXIF, it is what is in it, and there is a trap almost nobody mentions: IFD1, the second image directory behind IFD0's next-IFD pointer, normally holds an embedded thumbnail, and that thumbnail can be the unedited original. A file that looks stripped can still carry the frame the photographer did not choose to publish. The viewer also flags a MakerNote, which is a vendor block addressed by absolute file offset and is invalidated by any tool that re-encodes the file.
Worked example
Someone forwards a photo and asks whether it shows where their apartment is.
- The file is a JPEG whose APP1 segment starts with Exif\0\0, so there is an EXIF block to read
- The GPS IFD holds 33° 52' 6.2" with a reference of S, and 151° 12' 36.4" with E
- The S reference makes the latitude negative, giving -33.8684, 151.2101 decimal degrees
- ExposureTime is a RATIONAL of 1/125, shown as 1/125s rather than 0.008s
- IFD1 is present and holds a 9 KB thumbnail, which is the unedited original
The photo does contain an exact location, and the embedded thumbnail is a second copy of the original that most stripping tools leave in place. The reference letter, not the sign, is what put the point in the southern hemisphere.
Accuracy and limitations
- A missing EXIF block is a clean answer, not an error. Screenshots and flattened social exports have none, and that is the correct result for those files.
- MakerNotes are not decoded. They are vendor-specific blocks addressed by absolute file offset, so they are only meaningful in the exact file that wrote them.
- This reads EXIF, not every metadata format. AVIF and animated GIF have nowhere to carry it, and PNG text chunks that are compressed are reported rather than inflated.
Frequently asked questions
- Does this photo have GPS data?
- The viewer says so explicitly either way. If the GPS sub-IFD is present you get the coordinates in degrees, minutes and seconds with the hemisphere reference, converted to decimal degrees; if it is absent you get a clear statement that the file carries no location data at all.
- How do I remove location data before sharing a photo?
- Check what is in it here first, then use the metadata remover on this site. That tool re-encodes the pixels into a fresh file with no EXIF block at all, which is more thorough than clearing fields because it also removes the embedded thumbnail in IFD1.
- Does this upload my photo anywhere?
- No. The file is read as bytes in your browser and parsed with a DataView, and there is no map tile request, no geocoding lookup and no network call of any kind. Several other viewers contact a tile server to show a map, which is both a privacy leak and a surprise network cost.
- What is an IFD and why does it matter for privacy?
- An image file directory is a table of 12-byte entries holding the tags. IFD0 is the main one, but a second directory, IFD1, sits behind it and normally holds an embedded thumbnail — often the unedited original. A file that looks stripped can still be carrying that copy.
- Why does the shutter speed show as 1/125 rather than 0.008?
- Because the file stores it as a rational, a numerator over a denominator, and the parser keeps the raw pair. The decimal form has already discarded the denominator, and 1/125s tells you the camera's actual setting while 0.008s tells you nothing about the gear.
- Why is there no EXIF data in my file?
- That is the correct answer for a screenshot, a flattened social export, or anything that has already been through a metadata stripper. A viewer that reports a failure here would be lying about a result that is not one.