The result in one minute
A byte-preserving transfer kept every field we tested. A normal JPEG resize and a JPEG-to-WebP conversion removed all seven target field groups when the image pipeline used its default output settings. When the same pipeline was told to keep metadata, both outputs retained every target field.
The practical lesson is simple. Adding a geotag to the source file does not prove that a published copy still contains it. The result depends on the exact upload surface, the processing path, and the file a viewer can retrieve afterward.
- Source files: JPEG, PNG, and WebP, each carrying the same synthetic metadata.
- Measured fields: GPS, capture time, description, artist, copyright, software, and XMP keywords.
- Controlled outputs: one direct copy and four re-encoded files.
- Current platform result: one anonymized X web image observation, scoped to the browser-rendered small rendition.
Controlled pipeline results
We used one verified JPEG as the source for five delivery paths. The two default re-encodes changed the pixels and stripped every target field. The two equivalent re-encodes with metadata retention enabled also changed the pixels, but kept every target field. This is a controlled pipeline result, not a claim about the internal software used by any social network.
| Delivery path | File changed | GPS | Time | Text and rights | Classification |
|---|---|---|---|---|---|
| Byte-preserving file transfer | No | Kept | Kept | Kept | Byte-identical |
| JPEG resize, default output | Yes | Removed | Removed | Removed | Stripped |
| JPEG resize, keep metadata | Yes | Kept | Kept | Kept | Retained |
| JPEG to WebP, default output | Yes | Removed | Removed | Removed | Stripped |
| JPEG to WebP, keep metadata | Yes | Kept | Kept | Kept | Retained |
The source files
The test card is synthetic. It contains no person, private address, or customer photo. Its coordinate, 51.500729, -0.124625, is a fixed test value printed on the image as well as embedded in the file. The visible warning makes it difficult to mistake the card for real location evidence.
All three source formats were parsed after export. GPS, capture time, description, artist, copyright, software, and XMP keywords matched across JPEG, PNG, and WebP. Full SHA-256 values are in the manifest.
| Format | Bytes | SHA-256 prefix | GPS | EXIF and XMP |
|---|---|---|---|---|
| JPEG | 161,360 | 6f807885ea62 | Verified | Verified |
| PNG | 121,770 | cf124a7bc66f | Verified | Verified |
| WebP | 62,236 | 15e090d0ea4d | Verified | Verified |
How we classify a returned file
A platform can store an original, serve a processed preview, and offer a separate download. Those are different objects. We inspect the exact file returned by the named retrieval method and record that method with the result.
A downloaded copy cannot tell us everything a company stores internally. It only shows what that surface delivered on the test date. App versions, account types, regions, upload formats, and download routes can produce different results.
- Byte-identical: the returned SHA-256 matches the source file.
- Retained: the file changed, but every target field is still readable.
- Partial: at least one target field remains and at least one is missing or changed.
- Stripped: none of the target fields remains in the delivered file.
- Not downloadable: there is no supported route to retrieve a comparable file.
Current platform result: X
On 17 July 2026, we uploaded the verified JPEG source through the X web composer as a public image post. We then inspected the image loaded by the browser on the resulting public photo page. The observed rendition was a 680 by 425 JPEG, 32,985 bytes, with SHA-256 prefix 7c4d0b593670.
The returned file was not byte-identical to the 1600 by 1000 source. It contained no EXIF or XMP block, and none of the seven target field groups was readable. We classify this browser-rendered small rendition as stripped.
For account privacy, the public report and data files exclude the account name, handle, post URL, media URL, platform identifiers, and screenshots. The returned binary was inspected locally and is not distributed in the public kit. This privacy choice does not change the hash or metadata comparison.
| Surface | Returned copy | GPS | EXIF | XMP | Classification |
|---|---|---|---|---|---|
| X public image post | 680 × 425 JPEG, 32,985 bytes | Removed | Absent | Absent | Stripped |
What current platform documentation does and does not say
Google Business Profile documents accepted formats, file size, resolution, and photo quality. The public guidance we reviewed does not promise that embedded GPS, EXIF, or XMP will remain in the displayed copy. That absence is not proof that Google always removes the fields. It means the retention claim is not documented there.
Google Images is a separate surface. Google documents support for image licensing information supplied through IPTC metadata or structured data on a public web page. That should not be treated as evidence that a Business Profile photo keeps GPS metadata, or that a geotag improves local ranking.
| Surface | What the primary documentation confirms | Retention conclusion |
|---|---|---|
| Google Business Profile photos | JPEG or PNG, 10 KB to 5 MB, with resolution and quality guidance | No public EXIF, GPS, or XMP retention promise found in the reviewed guidance |
| Google Images on a public website | IPTC or structured data can provide creator, credit, and licensing details | Useful for supported image metadata fields, but not proof of GPS retention on another Google product |
| X public image post | Our current observation covers the browser-rendered small rendition | Stripped in the tested rendition; this does not describe internal storage or every X delivery path |
| Other social and messaging apps | Behavior depends on the named upload and retrieval surface | No current result is published here until we can retrieve and inspect a comparable file |
Historical platform benchmark
The most useful broad comparison we found is IPTC's 2019 Social Media Sites Photo Metadata Test. It used a reference image with known EXIF, IIM, and XMP values, then checked displayed data, browser-saved copies, and platform downloads. It is a sound model for repeatable testing, but the results are historical and should not be quoted as current platform behavior.
In that 2019 test, Twitter's browser-saved image had metadata stripped, Instagram did not display embedded metadata and offered no comparable download, Facebook retained only part of the tested rights data in some formats, and Google Drive passed through the original download. These are IPTC's 2019 findings, not GeoTag Photos results from 2026.
What this means for local SEO work
Use geotags as source-file organization and proof of location intent, not as a ranking promise. If the destination re-encodes an image, the delivered copy may lose the GPS even though the source file was prepared correctly.
For images hosted on your own site, keep a verified master, use descriptive page copy and alt text, and add structured data or supported IPTC licensing fields when they serve a real purpose. For Business Profile uploads, prioritize accurate business information, useful photos, and Google's published quality requirements.
- Verify the exported source before upload.
- Record the exact platform surface and retrieval method.
- Inspect the returned file instead of relying on the upload screen.
- Keep the original and checksum so later tests can be compared.
- Retest after major app or platform changes.
Reproduce or contribute a result
Download the kit, choose one source file, confirm its checksum, upload it through one precisely named surface, and retrieve the closest supported copy. Record the returned hash and inspect the seven target field groups. The included CSV keeps each observation tied to its date and retrieval method.
If you send us a result, include the returned file, source format, platform surface, test date, retrieval steps, and app or browser version. Do not send private photos. We will publish a platform row only when the evidence is reproducible and the scope is clear.