How to exif gps viewer vs google photos: which exposes more?
- Step 1Get the original file, not the cloud copy — Download the original from Google Photos / iCloud (the un-recompressed version) or use the file straight off the camera. A copy that already passed through a social platform has had EXIF stripped and will read as no-GPS everywhere.
- Step 2Drop the JPEG or TIFF into the local previewer — The tool parses JPEG and TIFF EXIF with
piexifjsin your browser. Unlike a cloud upload, this is the moment the comparison diverges: nothing is transmitted, no thumbnail is generated server-side, no location is recorded to an account. - Step 3Read the marker the local viewer renders — If GPS is present you get a Leaflet/OpenStreetMap marker at zoom 13 with the coordinates in the popup. If not, you get No GPS data found in EXIF — the same negative a cloud service would derive, but without keeping a record of the check.
- Step 4Compare against what the cloud service shows — Open the same photo in Google Photos' info panel or map view. The pin should match the local marker — both read the same EXIF GPS. The difference is that Google now has that location tied to your account and the local tool has discarded it.
- Step 5Decide your retention boundary — If the location is sensitive, the lesson is that uploading the photo anywhere already disclosed it. Audit locally first; only then decide whether to upload, share, or scrub.
- Step 6Scrub before any upload if the location must stay private — Run the photo through the EXIF Scrubber so that even if you later upload it to a cloud service, there is no GPS for the service to index. Re-preview to confirm the scrub worked.
Local EXIF previewer vs cloud photo services
Both read the same EXIF GPS coordinates. The difference is what happens to the file and the location afterward.
| Dimension | Local EXIF Map Previewer | Google Photos / iCloud / Amazon Photos |
|---|---|---|
| Where parsing happens | In your browser (piexifjs) | On the provider's servers after upload |
| What the file does | Never leaves your device | Full image uploaded and stored |
| Location retention | None — ephemeral {hasGps, lat, lon} | Indexed, searchable, kept with your account |
| Account / identity link | None | Tied to your logged-in profile |
| Third-party network calls | OSM tile requests for the area only | Upload, plus the provider's analytics pipeline |
| Disclosure risk | Nothing to subpoena or breach server-side | Location subject to provider policy, legal process, breach |
| Coordinates extracted | Latitude + longitude (decimal degrees) | Latitude/longitude plus often altitude, timeline, clustering |
What each side actually reads from the EXIF
The local previewer is deliberately minimal — it decodes only the two fields needed to drop a pin.
| EXIF field | Local previewer | Typical cloud service |
|---|---|---|
| GPS latitude / longitude | Decoded to decimal degrees, pinned | Decoded and stored, used for map + timeline |
| GPS altitude | Not read | Often stored |
| GPS direction / bearing | Not read | May be stored |
| GPS / capture timestamp | Not read | Used to order your timeline |
| Camera make / model, lens | Not read | Indexed for search/filtering |
| Faces / objects in the image | Never analysed | ML-clustered into people and things |
Cookbook
Scenarios where the local-vs-cloud distinction changes the privacy outcome. Coordinates are landmarks, not personal data.
The same photo, two pipelines
A single geotagged JPEG read both ways. The coordinates are identical; the consequences are not.
Photo: cafe_paris.jpg (EXIF GPS present)
Local previewer:
-> {"hasGps": true, "lat": 48.85840, "lon": 2.29450}
-> marker on OSM, nothing stored, tab closed = gone
Google Photos:
-> same pin shown in the info panel / map
-> location now in your account's place index forever
-> appears in "Places" search and timelineAuditing a source photo without leaving a trail
A journalist receives a sensitive image and needs the location, but uploading it to a cloud service would create a server-side record linking the journalist's account to that location.
Cloud path: upload -> location indexed under journalist's
Google account -> potential subpoena target
Local path: drop into previewer -> {hasGps, lat, lon}
-> read marker -> close tab -> no record exists
The second path is the only one with no retained artefact.Confirming a cloud service already stripped a shared copy
You forwarded a photo through a messaging app and want to verify the location is gone from the copy your recipient received.
Original (camera file) -> previewer -> hasGps: true Copy saved from WhatsApp -> previewer -> hasGps: false The app stripped EXIF on send; the recipient's copy carries no location. The original on your phone still does.
Scrub-then-upload so the cloud never indexes the location
If you do want a photo in Google Photos but not its location, remove the GPS before upload — the cloud service can only index what is in the file.
Step 1 previewer on original -> hasGps: true Step 2 /image-tools/exif-scrubber -> clean copy Step 3 previewer on clean copy -> "No GPS data found in EXIF" Step 4 upload the clean copy -> nothing for the cloud to index
Why the local pin and the cloud pin sometimes differ
If they disagree, it is almost always because you compared different files, not because either tool is wrong.
Local previewer reads: IMG_0042 original -> 51.50740, -0.12780 Google Photos shows: IMG_0042 'enhanced' -> no location Cause: the enhanced/edited cloud version was re-saved and lost EXIF. Always compare the same exact file on both sides.
Edge cases and what actually happens
The cloud service already has the location because you uploaded the photo
Already disclosedOnce a photo is in Google Photos or iCloud, its EXIF location has been read and stored server-side. Auditing locally afterward tells you what was exposed but cannot un-expose it. To keep a location private, scrub before any upload — the local-first order matters.
Comparing a cloud-edited copy against the original
Different filesCloud editors and 'enhance' features re-save the image and often drop EXIF. The edited cloud copy can read as no-GPS while the original is geotagged. A mismatch between the local marker and the cloud map usually means you compared two different versions of the file.
Local viewer reads less than the cloud service
By designThe local previewer decodes only latitude and longitude — it deliberately ignores altitude, bearing, timestamp, camera model, and faces. A cloud service extracts and indexes far more. If you need a complete metadata read, this tool is not it; it answers exactly one question: where on a map.
HEIC from a recent iPhone
Unsupported formatiCloud reads HEIC location natively; the local previewer uses piexifjs, which handles JPEG and TIFF only. Convert HEIC to JPEG before previewing locally, or you will see no location even though the cloud service shows one.
OSM tile requests still reveal the area to a third party
Minor exposureThe local viewer sends no file, but loading the map does request OpenStreetMap tiles for the surrounding area — so OSM's CDN sees roughly where you are looking, though never your file or your account. This is far less than a cloud upload, but it is not literally zero network activity.
GPS coordinates were faked before either tool saw them
Check the sourceNeither the local viewer nor the cloud service can tell a real coordinate from a spoofed one — both just decode the stored bytes. If location accuracy matters, corroborate with the image content; the privacy comparison is about retention, not authenticity.
Both report no GPS
Geotag-cleanIf the local previewer and the cloud service both show no location, the file genuinely carries none — taken with Location Services off, or already stripped. There is no location to leak in either pipeline.
Large original above the local size limit
413 rejectedA high-resolution TIFF can exceed the free 10 MB limit and be rejected by the local tool, while a cloud service would accept it. Upgrade to Pro (100 MB) or higher to audit oversized originals locally rather than falling back to a cloud upload.
Frequently asked questions
Do both tools read the same coordinates?
Yes — both decode the same EXIF GPS latitude/longitude triplet, so the pin is in the same place. The difference is entirely in what happens next: the cloud service stores and indexes the location under your account; the local previewer discards it when you close the tab.
Does the local previewer send my photo to anyone?
No. It parses the EXIF and renders the map in your browser. The only outbound traffic is OpenStreetMap fetching tiles for the area around the coordinates — the image itself is never transmitted, unlike a Google Photos upload.
If I already uploaded the photo, is checking it locally pointless?
Checking is still useful to understand what you exposed, but the cloud service already read and stored the location, so a local audit cannot retract it. The takeaway is to audit locally first next time, and scrub before uploading anything sensitive.
Why does Google Photos show a location but the local tool doesn't?
Usually because they are different files. Cloud-edited or 'enhanced' versions are re-saved and frequently lose EXIF, and HEIC originals are not parsed by the local tool. Compare the exact same JPEG/TIFF original on both sides.
Does Google Photos keep my location data permanently?
Cloud photo services read EXIF GPS on upload and retain it as part of your library's searchable place index, subject to their privacy policy and your account controls. The exact retention is governed by the provider, not by us. The local previewer retains nothing.
Can I see altitude or the photo's timestamp in the local viewer?
No. The local previewer decodes only latitude and longitude. Cloud services typically extract altitude, timestamp, camera model, and more; this tool intentionally reads just enough to drop a map pin and nothing else.
How do I make sure a cloud service never gets my location?
Strip the GPS before uploading. Run the photo through the EXIF Scrubber, confirm with this previewer that it now reports no GPS, then upload the scrubbed copy. The cloud can only index what is in the file.
Is the local viewer's map private?
More private than a cloud upload, but loading the map does request OpenStreetMap tiles for the area, so OSM's tile servers see the rough region you are viewing. They never see your file, your account, or your exact pin as a stored record.
What formats does the local tool support versus the cloud?
The local previewer reads JPEG and TIFF (via piexifjs); cloud services additionally handle HEIC, RAW, and more. For a HEIC iPhone photo, convert to JPEG before using the local tool, or the comparison will be apples-to-oranges.
Can either tool tell if coordinates were faked?
No. Both just decode the stored EXIF bytes. A spoofed coordinate reads as a real one in both. For authenticity, corroborate with the image's visible content and shadows; the local-vs-cloud distinction is about retention, not truth.
Is there a size limit on the local tool?
Yes — the Security family's free tier caps a single image at 10 MB, with Pro at 100 MB, Pro-media at 500 MB, and Developer at 2 GB. Cloud services accept much larger files, but that convenience is exactly what creates the retained record.
What other local checks complement this comparison?
Use the Magic-Byte Validator to confirm a file's true type, the Hex Header Inspector to inspect raw bytes, and the Entropy Analyzer to gauge whether a file is compressed or possibly carrying hidden data — all browser-local, like this previewer.
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.