Reading EXIF, GPS, and camera tags from photos privately
Published: 2026-09-05
What EXIF, IPTC, and XMP store in JPEG and other images, why GPS tags leak location, how camera settings show up in metadata, and how to inspect tags in the browser without uploading photos.
A photo file is more than pixels. Most phone and camera JPEGs (and many TIFF, HEIC, and WebP exports) carry metadata: structured tags for when the shot was taken, which camera and lens, exposure settings, and sometimes GPS coordinates. That baggage is useful for sorting a library—and risky when you share the same file on the open web.
This guide explains the common tag families, what GPS and camera fields mean in practice, and how to inspect them locally so the image never leaves your device.
What lives beside the pixels
Image formats can embed several metadata “namespaces.” They overlap in purpose but come from different eras and tools:
| Family | Typical role | Examples |
|---|---|---|
| EXIF | Camera/capture technical data | Make, model, DateTimeOriginal, FNumber, ExposureTime, ISO, GPSLatitude |
| IPTC | Editorial / press fields | Caption, keywords, credit, copyright notice |
| XMP | Adobe-style extensible RDF packets | Soft proofing, ratings, richer descriptions |
| ICC / file | Color profile and container hints | Color space name, dimensions, orientation |
You do not need every group on every file. A phone photo often has rich EXIF (and GPS if location was on). A screenshot or heavily recompressed social download may have almost nothing—platforms strip tags to save bytes and reduce leaks. A “no tags found” result is common and usually means the file was already cleaned, not that the viewer failed.
MIME types for the wrappers (image/jpeg, image/png, image/heic, …) are covered in MIME types and file extensions. Compression and re-encoding can drop or rewrite metadata even when the picture still looks fine (Lossy vs lossless image compression).
Camera and capture fields worth reading
When present, a short camera summary is enough for most debugging:
| Field | Why it matters |
|---|---|
| Make / model | Which body (or phone) wrote the file |
| Lens | Useful for photo workflows; often missing on phones |
| Date / time | Capture time (timezone rules vary by camera and software) |
| Exposure | Aperture, shutter, ISO—quick sanity check for “why is this noisy?” |
| Focal length | Optical or 35 mm-equivalent; phones may report digital crop oddly |
| Orientation | How viewers should rotate the bitmap (tag vs already-rotated pixels) |
| Software | Editor or OS that last saved the file |
| Color space | sRGB vs wider gamut; mismatch can tint exports |
Binary blobs such as MakerNote (vendor-private) and embedded thumbnails are often skipped in friendly UIs: they are large, not human-readable, and not needed for “where was this shot?” questions.
GPS: the privacy hot button
EXIF can store latitude, longitude, altitude, and related GPS tags. If location services were enabled when the photo was taken (or an editor wrote GPS later), anyone who downloads the full file can plot the coordinates—home address, travel route, a child’s school, a worksite.
Practical habits:
- Inspect before you share originals from phones and cameras, especially for public blogs, bug reports, and “drop this in Slack.”
- Prefer stripped exports for the public web (many CMSs and social apps strip EXIF; email and file-share links often do not).
- Treat GPS-positive files as sensitive the same way you treat screenshots with secrets (Why “local only” matters for developer tools).
Reading GPS tags is not the same as tracking someone live; it is reading a stored location from the file. Still, leaking that store is an avoidable own-goal.
Why inspect in the browser (not an upload site)
Online “EXIF viewers” often upload the image to a server, parse tags, then show a table. That is convenient—and a bad fit for vacation albums, ID photos, unpublished product shots, or anything with GPS. A local viewer loads the file with the File API, parses tags in JavaScript (for example with ExifReader), and never posts the bytes.
Same model as other LocalTools media utilities: pixels and coordinates stay on the device unless you copy or download an export of the tag list.
Caveats of in-browser readers:
- Some HEIC/AVIF files parse tags even when the browser cannot preview the image.
- Proprietary MakerNote payloads may be omitted.
- Dimensions may come from tags, the file header, or both—treat them as best-effort when formats are exotic.
Try it on LocalTools
Open Image Metadata Viewer:
- Drop one image (JPEG, PNG, WebP, GIF, TIFF, HEIC/AVIF, JPEG XL — max 32 MB).
- Check file name, MIME, dimensions, size, and the camera & capture summary (including GPS when present).
- Filter the full tag table by group, name, or value (EXIF, IPTC, XMP, and related).
- Copy JSON or TSV, or download
metadata.json—parsing stays in the tab with ExifReader.
If you only need a smaller file for the web (and do not care about keeping EXIF), re-encode with Image Optimizer. Canvas re-encode often drops original EXIF; verify with the metadata viewer if you need a clean public asset. For embedding tiny images in CSS/HTML, see Embedding images as Base64 data URLs—Base64 carries whatever metadata the source file still has unless you strip first.
Related reading
- Image Metadata Viewer — inspect EXIF, GPS, and tags locally
- Lossy vs lossless image compression — re-encoding and size vs quality
- PNG to favicon.ico and multi-size icon packs — icon pipelines where metadata rarely matters
- MIME types and file extensions
- Why “local only” matters for developer tools