Image EXIF Reader — Open a Photo and See What the Camera Wrote
Pick a JPEG, PNG, WebP or TIFF file and read the metadata the camera left in it: model, exposure, orientation, timestamps and GPS coordinates, decoded byte by byte in your browser from the file on your disk — the file never leaves this device.
What the camera was set to
| Item | Value |
|---|
Every tag found
| Directory | Tag | Id | Value |
|---|
Which fields, read from where
What gets read, and from where
EXIF is a TIFF directory hidden inside the picture file, and each container hides it differently. All four of the common ones are walked:
- JPEG — the segments after
FFD8are stepped over in order until the compressed image data starts. An APP1 segment whose body beginsExif\0\0is the one that holds the directory. TheSOFsegment is read too, because that is where the real pixel size lives; EXIF’s ownExifImageWidth/Heightare often stale or missing. - PNG — the
eXIfchunk added in PNG 1.5. Most PNGs have never heard of it. - WebP — the
EXIFchunk inside the RIFF list. - TIFF — the file is the directory, so it is read from byte zero.
Inside, IFD0 is followed, then the Exif and GPS sub-directories they point at, then IFD1, which is where a camera’s small preview image lives. If that preview is a real JPEG, it is shown; it is the one piece of picture data ever decoded.
Fields left blank rather than guessed
MakerNoteis not decoded. Every vendor invented their own format inside it, and a wrong guess looks exactly like a right one. You get the tag and its byte count.- HEIC/HEIF/AVIF is refused rather than faked. Their metadata sits in ISO-BMFF property items, not a TIFF block, and parsing that halfway produces confident nonsense.
- Broken offsets are reported, not repaired. If a directory claims more entries than the file holds, the overage is reported and only the entries actually present are read.
- No timestamp is invented. EXIF has
DateTime,DateTimeOriginal,DateTimeDigitizedand a GPS stamp, and they disagree surprisingly often — so the summary labels which one it printed.
The orientation number
Orientation is not a rotated picture; it is an instruction to whoever displays it. Value 1 means the pixel rows are already top-down. Value 6 means “rotate 90° clockwise to see it upright”, which is what most phones wrote before browsers started obeying image-orientation: from-image — and it is why a photo can look right in one app and sideways in another while both show the same bytes. The table above prints the number and the plain-language turn.
Why a photo can arrive empty
Messaging apps, social sites and most “send as photo” paths strip EXIF, both to shrink the upload and because GPS in a shared photo is a real privacy problem. Screenshots never had camera data. Re-exported files from editors keep only what the editor writes. A file with no EXIF block is a normal outcome, not an error, and it is reported plainly rather than as an empty table.
Questions
Q: Does the picture get uploaded? No. The bytes are read into this tab by the browser’s own file reader and parsed by loops running in the browser: the picture is never offered to a server, and it never leaves this device.
Q: My GPS shows a place I did not visit. The coordinates are decoded from the degrees/minutes/seconds rationals into WGS84 decimal degrees, exactly as written. If a phone wrote an approximate location, or a tool wrote a fake one, that is what shows up, not something invented — which is why the label reads “WGS84, decimal degrees” instead of a map pin.
Q: Why is the resolution 72 dpi when the photo is huge?
XResolution with ResolutionUnit = 2 is the print density a camera reports, nothing else. It has no bearing on the pixel size, which is read from the SOF segment.