Someone asks you for a photo and adds "please send it as a document, not as an image, quality kharab ho jaati hai." Reasonable request. WhatsApp compresses photos badly and sending as a file fixes that.
It also ships your GPS coordinates to them, accurate to about a third of a metre.
The compression you were avoiding was doing something else on the side: it was rebuilding the image from pixels and dropping every hidden block in the process. Turn the compression off and you turn the accidental privacy off with it.
Table of contents
- What is actually inside the file
- Why photo mode looked private
- How precise is that location, really
- The claim that metadata bloats your file
- PDFs store the same secret twice
- What survives a half-cleanup
- Do this before you send
- FAQ
- Conclusion
- Sources
What is actually inside the file
I built a 4032x3024 JPEG with the metadata a modern phone typically writes, then walked its markers byte by byte. The camera data does not sit in one field. It sits in three separate directories inside a single 778-byte APP1 segment.
Thirty-four populated tags across the three. IFD0 carried the make, model, software version and orientation. ExifIFD carried exposure, aperture, ISO, focal length, both timestamps, the lens description and the camera body serial number. The GPS directory carried eleven tags of its own: latitude, longitude, altitude, the satellite fix timestamp, compass bearing, and the date the fix was taken.
The serial number is the one people underestimate. It is a fixed identifier that links every photo from that handset to every other photo from it, including the ones you posted publicly years ago.
Why photo mode looked private
Send that same file through WhatsApp's gallery picker and the app recompresses it. Recompression means decoding the JPEG to a pixel grid and writing a new file from that grid, and a new file written from pixels has nowhere to put an APP1 segment.
I reproduced exactly that operation: decode, copy the pixels into a fresh image, re-encode. The result is the browser canvas trick our own bulk image metadata remover uses, and the numbers came out clean.
| Property | Original JPEG | After pixel-only re-encode |
|---|---|---|
| APP1 segment | 778 B | absent |
| Populated EXIF tags | 34 | 0 |
| GPS directory | present | absent |
| Pixel dimensions | 4032 x 3024 | 4032 x 3024 |
Nothing in that operation was designed to protect you. Privacy was a side effect of a bandwidth decision. "Send as document" skips the recompression, hands over the original bytes, and the side effect disappears with it.
That is why the advice "share as a file to keep quality" and the advice "share as a file to keep metadata" are the same sentence. Photography forums recommend it for the first reason. People documenting evidence recommend it for the second. Both are describing one behaviour.
How precise is that location, really
EXIF does not store a decimal latitude. It stores degrees, minutes and seconds, each as a fraction with its own denominator, and the seconds field is where resolution is decided.
A phone typically writes seconds with a denominator of 100, so the smallest step is one hundredth of an arc-second. Converting that to ground distance is one division:
One degree of latitude spans about 111,320 metres, so one arc-second is 111320 / 3600 = 30.92 metres. One hundredth of that is 0.309 metres.
Thirty-one centimetres. That is not "the neighbourhood you live in", that resolves which room of the house you were standing in. Longitude is slightly tighter in absolute terms because the meridians converge: at Delhi's latitude of 28.61 degrees, one arc-second of longitude covers 27.15 metres rather than 30.92.
I round-tripped the encoding to check the storage format was not quietly losing precision on the way in. Input 28.613900 degrees, decoded back to 28.613900 degrees, error 0.000 metres. The format keeps everything the GPS chip claimed.
Whether your phone's fix is genuinely accurate to 31 cm is a separate question, and usually it is not. But the file has room to record it at that resolution and will happily do so, and the recipient cannot tell the difference between a precise reading and a lucky one.
The claim that metadata bloats your file
Half the guides on this subject promise smaller files after cleaning. I measured it on the pair above and the result went the other way.
| File | Bytes |
|---|---|
| With full EXIF and GPS | 803,052 |
| After stripping, pixel-identical | 803,161 |
The cleaned file is 109 bytes larger. Removing 778 bytes of metadata grew the file, because re-encoding the pixel grid produced slightly different entropy coding than the original pass did, and that difference outweighed the segment I deleted.
So strip metadata for privacy. The storage saving is a rounding error on any real photo, and on this one it does not exist at all.
PDFs store the same secret twice
Images have one hiding place. PDFs have two, and that is the trap.
The older location is the document information dictionary, which holds Title, Author, Subject, Keywords, Creator and Producer. It is what File then Properties shows you in any viewer. The newer location is an XMP packet: an XML block embedded in the file, written by most modern editors in addition to the old dictionary.
I assembled a PDF by hand with both copies populated, the way a Word export arrives, and counted the bytes.
The XMP packet alone was 1,010 bytes. On a short document the two copies together came to 64.8% of the entire file, which tells you how much of a small PDF can be identifying information rather than content.
The XMP block carried something the visible Properties panel never shows: a pdfx:Company field. Word writes your organisation name there from your Office installation. Nobody types it, nobody sees it, and it travels with every PDF you export.
What survives a half-cleanup
Clearing only the fields you can see is the common mistake. I ran the byte-level grep on all three versions, looking for each identifying string the way a recipient with a text editor would.
| Field | Original | Info dict cleared only | Both cleared |
|---|---|---|---|
| Author name | leaks | still leaks | gone |
| Company name | leaks | still leaks | gone |
| Producing software | leaks | still leaks | gone |
| Internal draft filename | leaks | still leaks | gone |
| Edit timestamp | leaks | still leaks | gone |
| Internal subject line | leaks | gone | gone |
| Document ID | leaks | still leaks | still leaks |
Clearing the visible fields removed exactly one of seven. Six identifying fields survived in the XMP copy, including the author name and the company, because the two copies are independent storage and emptying one does nothing to the other.
The worse part is what a viewer does with the disagreement. Several PDF readers prefer XMP when both exist, so you can clear the Author box, save, reopen the file, and watch the old name reappear. It looks like the edit failed. The edit worked, the reader is reading the copy you did not touch.
Note the last row. The document ID, a fixed identifier in the trailer, survived clearing both metadata copies. Removing it takes a tool that explicitly targets it, which is why our PDF metadata editor drops the XMP stream and the document ID together rather than just blanking the six fields you can see.
Do this before you send
The rule that covers almost every case: if you are sending as a file rather than as a photo, clean it first, because nothing in the transfer will clean it for you.
For images, know which of the two things you want. Quality means send as document, which keeps everything. Privacy means let the app compress, which keeps nothing. If you want both, strip the metadata yourself and then send the stripped file as a document, which is what the batch tool is for when you have thirty photos rather than one.
For PDFs, verify rather than trust. Clear the fields, save, reopen the saved file and check the Properties panel again. If a value you cleared has come back, you edited one copy and the reader is showing you the other.
Two things no metadata tool can do for you. It cannot remove what is visible in the pixels, so a street sign, a licence plate, or a name on an envelope stays exactly where it is. And it cannot help with a platform that keeps its own copy of the original upload, which several do regardless of what the file you handed over contained.
FAQ
Does sending a photo as a document on WhatsApp keep the GPS location?
Yes. Document mode transfers the original file without recompressing it, so the EXIF block including the GPS directory arrives intact. The recipient can read your coordinates from the file. Photo mode recompresses the image, which rebuilds it from pixels and drops the metadata as a side effect.
How accurate is the GPS in a photo's EXIF data?
EXIF stores coordinates as degrees, minutes and seconds with the seconds typically at a denominator of 100, giving a smallest step of 0.01 arc-seconds. Since one arc-second of latitude is 30.92 metres, that step is 0.309 metres. The format can record your position to roughly a third of a metre.
Does removing metadata make my photo smaller?
Barely, and sometimes not at all. In a measured test on a 4032x3024 JPEG, removing a 778-byte EXIF block produced a file 109 bytes larger, because re-encoding the pixels changed the entropy coding. Remove metadata for privacy rather than for file size.
Why does the author name come back after I clear it in a PDF?
Because the PDF stored it twice. You cleared the document information dictionary, but the XMP packet still holds the old value, and many viewers prefer XMP when both exist. The fix is a tool that removes the XMP stream as well as the visible fields.
What is the pdfx:Company field in a PDF?
An XMP field that Microsoft Word populates from your Office installation's organisation name. It does not appear in the standard Properties panel, so most people never learn it is there, and it is exported with every PDF.
Does the document ID identify me?
Not by name, but it is a fixed value that stays with the file, so two documents carrying the same ID are demonstrably related. It sits in the PDF trailer rather than in either metadata block, so clearing the Info dictionary and the XMP packet both leave it in place.
Can metadata removal hide a face or a licence plate?
No. Metadata lives outside the pixel data, so stripping it changes nothing you can see. Anything visible in the image needs the pixels themselves edited.
Conclusion
Photo mode was never protecting you on purpose. It compressed to save bandwidth and lost your GPS coordinates along the way, and the moment you switch to document mode to protect image quality you get the original bytes back, camera serial and 31-centimetre location included.
PDFs are the same shape of problem with a nastier detail: clearing the six fields you can see removed one identifying field out of seven in my test, and the author name and company name sat untouched in an XMP block the Properties panel never displays.
Both fixes are mechanical. Rebuild the image from its pixels, and remove both PDF metadata copies rather than the visible one. The part worth remembering is that you cannot tell from looking at a file which of these has happened, so the check belongs before you hit send rather than after.
Sources
- All byte counts, tag counts, precision arithmetic and leak comparisons in this post were measured locally: a 4032x3024 JPEG constructed with a full EXIF, ExifIFD and GPS directory then marker-walked segment by segment, and a PDF assembled by hand with both an Info dictionary and an XMP packet, then grepped at the byte level after each cleanup stage.
- EXIF 2.32, published 2019 by the Japan Electronics and Information Technology Industries Association, defines the APP1 segment layout, the GPS IFD tag set and the rational storage format for coordinates.
- Apple Support, "Manage location metadata in Photos" (Personal Safety User Guide), documents removing location from a photo via Adjust Info, Adjust Location, No Location.
- Google Photos Help, "Understand, find and edit your photos' locations", states that a location written automatically by the camera cannot be edited or removed in Google Photos, only estimated or manually added locations can.
- WGS84 mean value of 111,320 metres per degree of latitude, used for the arc-second conversion; the longitude figure at 28.61 degrees N applies the cosine of the latitude.
