How to reading photo gps metadata for journalism and osint
- Step 1Obtain the original, unshared file — Insist on the camera original from the source — not a screenshot, not a re-download from a chat app. Instagram, X, WhatsApp, Facebook, and Telegram strip EXIF on upload, so a socially-shared copy will read as no-GPS regardless of the original.
- Step 2Verify the file is what it claims before trusting its metadata — Run it through the Magic-Byte Validator to confirm it is a genuine JPEG/TIFF and not a renamed or re-wrapped file. Garbage in the container can produce misleading or absent EXIF.
- Step 3Drop it into the EXIF Map Previewer — The tool reads the
GPSIFD locally withpiexifjsand returns{hasGps, lat, lon}. Nothing is uploaded; the location of a sensitive source photo never reaches a server. - Step 4Read the pin against the claimed location — If GPS is present, a marker drops on OpenStreetMap at zoom 13; the popup gives coordinates to five decimals. Compare the pin to where the source said the photo was taken. A mismatch is a lead; a match is corroboration, not proof.
- Step 5Cross-reference the coordinates externally — Copy the decimal degrees into Google Earth or satellite imagery to match buildings and terrain, and into a sun-position tool to check whether shadows in the image are consistent with the location and the claimed time.
- Step 6Treat the GPS as one signal, not the verdict — EXIF GPS can be faked, and this tool reports only what is stored. Build the geolocation case from converging evidence — metadata, content, shadows, landmarks — and document each step.
What the previewer gives an investigator — and what it doesn't
Know the tool's exact scope so you do not over-claim from a single read.
| Question | Answer from this tool | Where to get the rest |
|---|---|---|
| Where was it taken? | Latitude/longitude pin (if GPS present) | Cross-reference satellite imagery + content |
| Was GPS stripped or never set? | Inferred: no-GPS notice + provenance of the file | Chain of custody from the source |
| What altitude / direction? | Not provided | A full EXIF dump tool (the previewer reads lat/lon only) |
| When was it taken? | Not provided (no timestamp read) | Full EXIF dump; sun-position vs shadows |
| Is the coordinate authentic? | Cannot tell — reports stored bytes only | Content analysis, landmarks, corroboration |
| Is the file a real JPEG? | Not its job | Magic-Byte Validator |
EXIF survival across common source channels
Whether a photo still carries GPS depends heavily on how it reached you. General behaviour as of 2026.
| Channel | EXIF GPS survives? | Investigator implication |
|---|---|---|
| Camera original (SD card / direct) | Yes | Best source; preview directly |
| Email attachment (sent as file) | Usually yes | Reliable if not 'optimised' by the client |
| AirDrop / direct transfer | Yes | Preserves original bytes |
| Instagram / Facebook / X | No (stripped on upload) | Reads as no-GPS; request the original |
| WhatsApp / Telegram (compressed) | No (re-encoded) | Use 'send as document' or get the original |
| Screenshot of a photo | No (never had it) | Worthless for location; get the file |
Cookbook
OSINT-style triage cases. Coordinates are landmarks; treat every result as a lead to verify, not a conclusion.
GPS corroborates a source's claimed location
A source says a photo was taken at a specific square. The embedded GPS pins within metres of it — supporting, though not proving, the account.
Source claim: "taken at the Brandenburg Gate, midday"
Previewer:
{
"hasGps": true,
"lat": 52.51630,
"lon": 13.37770
}
Marker: on the Brandenburg Gate at zoom 13.
Next: confirm building geometry in satellite imagery and
check shadow direction against a midday sun for that date.GPS contradicts the claimed location
The strongest use of metadata triage: the stored coordinates point somewhere the source did not mention, opening a new line of inquiry.
Source claim: "photographed in City A"
Previewer:
{
"hasGps": true,
"lat": 41.89020,
"lon": 12.49230
}
Marker: lands in City B, ~600 km away.
Lead: the GPS could be authentic (source mistaken/lying) OR
spoofed. Do not publish; corroborate independently.No GPS because the file came through a social platform
A photo forwarded from a chat app reads as no-GPS. That is the platform stripping EXIF, not evidence the original was clean.
File: forwarded_from_telegram.jpg
Previewer:
{ "hasGps": false }
-> "No GPS data found in EXIF"
Action: request the camera original. The platform copy cannot
tell you anything about the location.Vetting the file before trusting its EXIF
Before relying on coordinates, confirm the file is a real image and not a renamed or padded container that could carry misleading metadata.
Step 1 /security-tools/magic-byte-validator
-> Detected: .jpg (image/jpeg), Claimed: .jpg [match]
Step 2 EXIF Map Previewer
-> {"hasGps": true, "lat": 48.85840, "lon": 2.29450}
Step 3 /security-tools/entropy-analyzer (optional)
-> flat-ish entropy: not obviously carrying hidden dataPossible coordinate spoofing flagged by content mismatch
The GPS says one place; the visible signage and architecture say another. The tool reports stored bytes faithfully, so the discrepancy is the finding.
Previewer pin: a coastal town Image content: alpine peaks, German-language road signs Conclusion: the EXIF GPS is inconsistent with the scene. Metadata alone is unreliable here -- weight the visual evidence and document the contradiction.
Edge cases and what actually happens
Source sent a socially-shared copy, not the original
Stripped upstreamInstagram, Facebook, X, WhatsApp, and Telegram strip or re-encode EXIF on upload. A copy from any of them reports no GPS even when the original is heavily geotagged. Always request the camera original; a platform copy is forensically near-useless for location.
Coordinates may be deliberately spoofed
Authenticity unknownEXIF GPS is just editable bytes. The previewer reports what is stored, not whether it is true. A confident-looking pin can be fabricated. Never treat a single coordinate as proof — corroborate with content, shadows, landmarks, and an independent chain of custody.
You need altitude, bearing, or the capture time
Not providedThis tool decodes latitude and longitude only and returns {hasGps, lat, lon}. GPS altitude, direction/bearing, and the GPS timestamp are not read. For those fields use a full EXIF-dump tool; for time-of-day verification, cross-check shadows with a sun-position calculator.
HEIC original from a modern phone
Unsupported formatpiexifjs parses JPEG and TIFF, not HEIC. A source's .heic will not yield coordinates here. Convert to JPEG without re-geotagging, then preview the JPEG. Note the conversion step in your documentation so the provenance stays clean.
Malformed or partial GPS tags
No location dataDecoding requires a full degrees/minutes/seconds triplet for both latitude and longitude. Cameras or editors that wrote partial GPS produce a NaN conversion, so the tool reports no GPS rather than a false pin. Absence of a pin is not absence of evidence — note it and pursue other signals.
Coordinates near 0,0 (null island)
Check the sourceA pin in the Gulf of Guinea usually means a zeroed or corrupt GPS field, not a real mid-Atlantic photo. Treat near-zero coordinates as a data artefact and verify the raw EXIF before drawing any conclusion.
Working on a network that blocks OSM tiles
Tiles blockedThe coordinate decode happens locally, but the basemap needs OpenStreetMap's tile CDN. On a restricted network the marker may sit on a blank canvas. The numbers in the popup are still valid — copy them into an offline mapping tool if needed.
Source photo exceeds the file-size limit
413 rejectedA high-resolution RAW-derived TIFF can exceed the free 10 MB cap and be rejected before parsing. Upgrade to Pro (100 MB) or higher, or down-convert to a smaller JPEG (documenting the step) to read the GPS.
Frequently asked questions
Is auditing a source photo here actually private?
The file never leaves your browser — piexifjs parses it locally and Leaflet renders the map. The only outbound traffic is OpenStreetMap tile requests for the area, which reveal roughly where you are looking but never the file or your identity. There is no server-side record of the audit, unlike a cloud geolocation upload.
Can I trust EXIF GPS as proof of where a photo was taken?
No. EXIF GPS can be edited or fabricated, and the tool reports only the stored bytes. Use it as triage and corroboration: match the coordinate against satellite imagery, landmarks, signage, and shadow direction before treating a location as established.
Why does a photo from my source show no GPS?
Most often because it reached you through a platform that strips EXIF (Instagram, WhatsApp, Telegram, X), or it is a screenshot, or it was taken with Location Services off. Request the original camera file; a re-shared copy cannot tell you the location.
Does the tool show me the time the photo was taken?
No. It decodes latitude and longitude only. For the timestamp use a full EXIF reader, and to validate the time independently compare the shadows in the image against a sun-position calculator for the candidate location and date.
How do I verify the coordinate against the real world?
Copy the decimal degrees from the marker popup into Google Earth or a satellite-imagery viewer and match building footprints, roads, and terrain. Then check that visible landmarks and shadow angles are consistent. Convergence across independent signals is what makes a geolocation defensible.
What if the GPS contradicts what the source told me?
Treat it as a lead, not a verdict. A contradiction can mean the source is mistaken or deceptive, or that the coordinate was spoofed. Do not publish on the metadata alone — corroborate the actual location independently and document the discrepancy.
Can I check several source photos at once?
No — the tool previews one photo and shows one marker at a time. For a set, preview each file individually and record each coordinate. There is no multi-pin or batch view.
Should I verify the file itself before trusting its metadata?
Yes. Run it through the Magic-Byte Validator to confirm it is a genuine JPEG/TIFF, and optionally the Entropy Analyzer to gauge whether it might be carrying hidden data. A file that is not what it claims can produce misleading EXIF.
What formats does it read?
JPEG and TIFF, via piexifjs. HEIC, PNG, and WebP will not return coordinates. For a HEIC original, convert to JPEG first and note the conversion in your provenance log.
Are there legal considerations to reading a source's EXIF?
Reading metadata in a file you legitimately hold is generally accessible, but publishing a person's location derived from EXIF can raise privacy and safety issues. Follow your publication's legal and ethics guidance, especially for vulnerable subjects or conflict zones.
How big a file can I audit?
Free tier caps a single image at 10 MB. Pro raises it to 100 MB, Pro-media to 500 MB, and Developer to 2 GB. Most source JPEGs fit the free tier; very large TIFFs may need an upgrade or a documented down-conversion.
How does this compare to a cloud geolocation service?
A cloud service uploads and retains the location under your account; this reads the same coordinates locally and keeps nothing. For OSINT work where leaving no trail matters, the local read is the safer default — see the EXIF GPS Viewer vs Google Photos comparison.
Privacy first
Every JAD Security operation runs entirely in your browser. Files, passwords, and PGP private keys never leave your device — verified by zero outbound network requests during processing.