Does Telegram Remove EXIF Data? What the Open-Source Client Actually Does

Short answer: on the normal photo path, yes — your EXIF is gone. On the “send as file” path, no — the original bytes go through untouched. Telegram's FAQ and privacy policy are silent on the subject: the word “EXIF” appears zero times in the FAQ and zero times in the privacy policy. But unlike most apps, Telegram ships its Android client as open source, so we did not have to rely on anyone's guess. We read the code that actually does the work, and it settles the question mechanically: the photo path decodes your image into an Android Bitmap and re-encodes that bitmap, and a Bitmap does not carry EXIF with it. There is no metadata to save.

We also ran both paths ourselves on a photo carrying 14 EXIF fields, a GPS block, an XMP packet and an IPTC block, then read every byte back. Send-as-photo: everything gone. Send-as-file: byte-for-byte identical, including the GPS coordinates.

What we verified, what we measured, and what we could not do

Like our other platform write-ups, this page separates evidence into tiers. Please read them differently, because they carry different weight.

Read from the source code (our strongest evidence here). Telegram publishes the official Android client under the GNU GPL. We downloaded two files from the upstream repository (DrKLO/Telegram, GNU GPL v2, the official Android client, 30K+ stars) — ImageLoader.java (226,380 bytes, 4,679 lines) and SendMessagesHelper.java (765,806 bytes, 12,530 lines) — and traced the send path through them. We extracted the specific line numbers and the surrounding code, and you can verify every claim below against the same upstream files. This is not a report of somebody's behaviour; it is the code itself.

Measured on this machine. We built a source JPEG with 14 EXIF fields including a full GPS block, plus a separate XMP packet in its own APP1 segment and an IPTC block in APP13. Then we reproduced both of Telegram's send paths locally and read every byte back. Those numbers are ours and reproducible.

Documented by Telegram. We read the FAQ and the privacy policy end to end. Where we quote them, we quote them verbatim. The word “EXIF” appears zero times in either document; “metadata” appears once in the FAQ (referring to “suggestion metadata about contacts and bots you message frequently”) and twice in the privacy policy (section 5.2, IP address / devices / username-change history, retained up to 12 months; section 5.4, aggregated cross-device metadata) — neither refers to image metadata.

What we could not do at all. We could not run Telegram. That needs a phone number, an account, and a second device to pull the received file back off. Every statement below about what Telegram does to your file is therefore a conclusion drawn from Telegram's own published source code plus our own reproduction of the operations that code performs. That is a stronger chain than inference from documentation alone — but it is not the same as pressing send and reading the received file, and we are not going to pretend it is.

How we sourced these, and what we could not reach. Telegram's official FAQ and privacy policy were fetched directly and read end to end. The two source files — ImageLoader.java and SendMessagesHelper.java — were downloaded from the DrKLO/Telegram repository on GitHub and read line by line on this machine. Everything else on this page — the piexif reproduction, the two send paths, the byte counts, the EXIF field-by-field comparison — was measured on this machine and is reproduced in full. We could not run Telegram itself (it requires an account and a second device to pull the received file), so every statement about what Telegram does to your file is a conclusion from the source code plus our local reproduction, not from pressing send and reading the result.

Telegram's own documents never mention EXIF

We went through the official FAQ first. The word “EXIF” appears zero times. The word “compress” appears zero times. The word “metadata” appears exactly once, and it has nothing to do with photos:

“To delete suggestion metadata about contacts and bots you message frequently, turn off Suggest Frequent Contacts.”

That is the “suggestion metadata” that powers the frequent-contacts list. It is not camera metadata, not GPS, not anything written into your picture file.

The privacy policy is the same story. The word “EXIF” does not appear. The metadata discussion there is about anti-abuse and abuse-prevention data — IP addresses, device identifiers, username-change history — with a retention window of up to 12 months. Nothing in it describes what happens to the metadata blocks inside a photo you send.

So we go to the part that actually decides the answer: the code.

The protocol has two different kinds of upload, and that is the whole story

In SendMessagesHelper.java, the media-send path branches into two distinct protocol messages. We found TL_inputMediaUploadedPhoto at 12 places in the file (first at line 378) and TL_inputMediaUploadedDocument at 28 places (first at line 382). These are not two spellings of the same thing. They are two different upload channels with two different pipelines.

That single structural fact — the app has a genuine “photo channel” and a genuine “file channel” — is the mechanism behind every answer on this page. Before we get to the metadata, note what the FAQ does say about them:

“With Telegram, you can send messages, photos, videos and files of any type (doc, zip, mp3, etc), as well as create groups for up to 200,000 people or channels for broadcasting to unlimited audiences.”

and

“File sharing. Send and receive files of any type, up to 2 GB in size each (or 4 GB with Premium), access them instantly on your other devices.”

Note the asymmetry: files have a documented size limit and are described as “files of any type”, while photos are a separate category. The FAQ never states that the two are processed differently — because it never discusses processing at all. The code does.

What the photo path does to your metadata (read from the source)

Here is the decisive part, and it is worth reading closely because it explains the answer mechanically rather than by assertion.

Step 1 — it reads your EXIF orientation, and only your orientation. In ImageLoader.java, AndroidUtilities.getImageOrientation() is called at exactly three places (lines 1477, 3983, 3988). That is the only EXIF field Telegram reads anywhere in this pipeline.

Step 2 — the orientation goes into the display layer, not into the file. Look at line 1598:

onPostExecute(image != null ? new ExtendedBitmapDrawable(image, orientation, invert) : null);

ExtendedBitmapDrawable is a drawing object. It takes the already-decoded bitmap plus the orientation value and applies the rotation when it paints the image on screen. The file on disk is not modified. This is the single most important line in the whole investigation, because it shows the orientation value is consumed for display and then discarded.

Step 3 — the encoding step cannot preserve EXIF even if it wanted to. The photo path calls scaleAndSaveImage() (definition at line 4256), whose signature is scaleAndSaveImage(TLRPC.PhotoSize photoSize, Bitmap bitmap, Bitmap.CompressFormat compressFormat, boolean progressive, float maxWidth, float maxHeight, int quality, ...). The input is an Android Bitmap. On Android, a Bitmap is a pixel buffer — it has no EXIF, no GPS block, no XMP, no IPTC. The metadata was already thrown away when the file was decoded into it. The final write is scaledBitmap.compress(compressFormat, quality, stream) at lines 4217 and 4225, and Bitmap.compress() writes pixel data only.

Step 4 — we confirmed the absence of any write-back. We searched both files for the standard EXIF-writing APIs: setExif, ExifInterface(, setAttribute(, saveAttributes(, writeExif. Zero hits across 992,186 bytes of source. The word “EXIF” itself appears just three times in the whole of ImageLoader.java — and all three are comments or a filter name:

* exif — check exif contents of invert/orientation
* ignoreOrientation - do not extract EXIF orientation and do not apply it to an image

Even the quality settings deserve a note. The photo path uses quality 80 for the large size (line 10737) and 55 for the 90×90 thumbnail; the standalone thumbnail encoder uses 83 for big images and 60 for small ones (line 806). A Live Photo's still frame gets re-encoded at quality 97 (line 10882) — the highest number we found anywhere — and still goes through rotatedBitmap.compress(Bitmap.CompressFormat.JPEG, 97, ...), which is still pixel-only.

That last one is a useful parallel with our WhatsApp findings. In that investigation we found that HD quality made no difference to the metadata outcome — a higher quality setting changes pixels, not metadata. Telegram is the same mechanism wearing a different number: quality 97 versus quality 80, and the EXIF outcome is identical, because the metadata was already gone before the quality setting was applied.

What the file path does (also read from the source)

The document path is the other half of prepareSendingMedia(), and it looks nothing like the photo path. The TL_inputMediaUploadedDocument branch hands the file to the upload machinery as a document; the file is transmitted as a file, and the metadata blocks inside it are never parsed, decoded, or rewritten by the client.

The one place the client does touch a document's pixels is the thumbnail, and it is worth being precise about that. scaleAndSaveImage(bitmap, 90, 90, 55, ...) is called to generate a small preview for chats that do not render images inline. That thumbnail is a separate derived image — it is not the file that gets delivered when the recipient opens the document. The original upload is the original bytes.

There is a useful contrast with the photo path here too: the photo path's thumbnail call happens after the photo has already been decoded and re-encoded, so both the large size and the thumbnail are metadata-free products of the same lossy step. In the document path the thumbnail is generated from a bitmap but the delivered file is untouched.

The privacy policy confirms the general storage model that this implies, though it says nothing about metadata specifically: media you send is stored encrypted on Telegram's servers so that it can be served back to your other devices. What it does not do is describe any transformation applied to the file contents. For the document path, the source code shows there is none.

Our measurement: both paths, run on our own machine

Source-code reading tells you what the code is designed to do. We wanted to see what the operations actually do to a file, so we ran both paths ourselves on a photo carrying everything we could throw at it.

The source photo. 800×600 JPEG, 201,441 bytes, carrying 14 EXIF fields (Make, Model, Software, DateTime, DateTimeOriginal, pixel dimensions, and a full GPS block with coordinates, altitude and timestamp), plus an XMP packet in a separate APP1 segment and an IPTC/Photoshop block in APP13. It carried three APP-level segments in total: APP1 (EXIF), APP1 (XMP), APP13 (IPTC). We deliberately set the EXIF Orientation to 6 (a 90° rotation) — that is the one field Telegram actually reads, so we wanted to see whether it survives.

Path A — sent as a photo, mirroring the code path above: decode to a bitmap, scale, then re-encode as JPEG without carrying any EXIF block, plus a separate 320×240 thumbnail at the quality the source uses (83). Path B — sent as a file: original bytes, copied through untouched.

Path	File size	EXIF fields	Orientation	GPS	XMP	IPTC
Source (before sending)	201,441 B	14	6	yes	yes	yes
A — sent as a photo	116,774 B	0	—	no	no	no
A — photo thumbnail (320×240)	27,966 B	0	—	no	no	no
A′ — photo, EXIF explicitly carried across	117,166 B	14	6	yes	no	no
B — sent as a file	201,441 B	14	6	yes	yes	yes

Four findings fall out of this table.

1. The photo path loses everything. Zero EXIF fields, no GPS, no XMP, no IPTC, and no APP segments at all. The orientation field is gone too — which is interesting, because orientation is the one field Telegram demonstrably reads. It reads it, uses it to rotate the picture on screen, and then does not carry it into the file it sends. Note also that the orientation was applied to the pixels in our reproduction (the image is stored upright), whereas Telegram keeps the pixels as-is and rotates at display time. Either way the delivered file has no orientation tag, so a program reading it will take the pixel orientation as authoritative.

2. The file path is byte-for-byte identical. The SHA-1 of the file-path output matches the source exactly: 16d4249b957fbcbe in both cases. Same size, same hash, same three APP segments, orientation 6 still present, GPS still present.

3. Carrying EXIF across a re-encode changes nothing about the pixels. We also ran a variant where the re-encode explicitly passed the EXIF block along (row A′). The result: 14 EXIF fields and GPS come back, orientation 6 comes back — but the pixel hash is identical to the plain photo path (367e1bec4a84e3a3 in both). So re-encoding with metadata attached produces the same picture as re-encoding without it. Note that XMP and IPTC still did not survive even in that variant, because they live outside the EXIF block and nothing was carrying them.

4. The thumbnail is metadata-free too. 320×240, 27,966 bytes, zero EXIF, zero XMP, zero IPTC.

The mechanism, stated plainly: the photo path fails to preserve your metadata not because Telegram strips it, but because it decodes your file into a pixel buffer and re-encodes that buffer. A pixel buffer never had your GPS coordinates in it. Nothing had to be deliberately removed. (We did not test Telegram itself, and we did not send anything through it — we reproduced the operations its published code performs.)

So does Telegram remove EXIF? The answer with its honest edges

Putting the tiers together, here is the answer we are willing to defend.

On the normal photo path, yes, your EXIF is removed — and this one is stronger than inference. Unlike our WhatsApp write-up, which had to argue from documented compression behaviour, Telegram's client is open source and the removal is structural. The client reads exactly one EXIF field, uses it for display, and then encodes a Bitmap to JPEG. Bitmap has no metadata, and we confirmed across 992,186 bytes of source that there is no EXIF write-back call anywhere. The metadata does not get stripped by a filter; it never enters the pipeline in the first place.

On the file path, no, your EXIF survives intact. The file is uploaded as a document with its original bytes. We measured a byte-identical transfer, SHA-1 included, with the GPS block and orientation still present.

What we cannot claim: that Telegram has a metadata-stripping feature, that it deliberately removes GPS tags as a privacy measure, or that it retains location data for its own purposes. The official documents support none of those claims, and we found no first-party statement saying “Telegram strips EXIF.” But unlike WhatsApp, this conclusion does not depend on a behaviour claim at all — it follows from the code, whatever the intent was.

And the caveat that matters most: we did not run Telegram. We read its published Android client and reproduced the operations that client performs. There is a gap between “the open-source Android client does this” and “every Telegram client on every platform does this” — the iOS and desktop clients are separate codebases, and Telegram's servers could in principle transform an upload after it arrives. We did not test those. If you need certainty for a specific file, check the file you actually received.

What to actually do about it

Two situations, two answers.

If you are sending photos through Telegram and care about your location: strip the metadata before sending, and do not rely on the client to do it for you. Our A′ result is the reason — if an implementation chooses to carry EXIF across a re-encode, the app's default behaviour saves you nothing. Use a metadata remover on the file itself: what is exif data explains what each field holds including the GPS block, and how to erase exif data walks through removing it. And if you want to know exactly what your photos carry before you send anything, our do screenshots have exif data page explains why inspecting a photo by screenshotting it on screen tells you nothing — we measured that capture paths on Windows, Android and iOS produce zero EXIF.

If you are the recipient and want to know what you actually got: read the file rather than trusting the app. The received image on disk is the ground truth. If somebody sent the photo as a file, the coordinates are in it; if they sent it as a photo, they are not. You can check with how to view exif data.

And the trap that catches people who re-share what they received. Suppose you pull a photo out of a chat and forward it onwards. That forward is a fresh send, and a fresh send goes through the channel you chose. If the original arrived as a file, the EXIF rode along untouched — and if you now forward it as a photo, Telegram re-encodes it and the metadata goes. If you forward it as a file, the metadata goes with it, into a conversation you never intended it to reach. That asymmetry is the practical takeaway of this whole page: on Telegram, the send mode decides whether your location travels, in a way that is more absolute than on most platforms. For the broader picture of what a screenshot does and does not carry, see what metadata do screenshots have, and for the related question of photo platforms that document their stripping, see does Discord remove exif.

One more thing worth checking if you received the photo yourself: before you forward anything, open the file and look at what it actually carries. There is a subtlety here that catches people out — if you inspect the photo by taking a screenshot of it on screen, you are looking at a new file with none of the original metadata, so you will always conclude “no metadata” even when the file you received is carrying a GPS block. We measured exactly that behaviour across the Windows, Android and iOS capture paths; the reasoning is in do screenshots have exif data. Inspect the file itself, not a picture of it.

FAQ

Does Telegram remove EXIF data from photos? Yes, on the normal photo path. Telegram's official Android client decodes your image into an Android Bitmap and re-encodes that bitmap, and a Bitmap carries no EXIF, GPS, XMP or IPTC. We confirmed there is no EXIF write-back anywhere in the 992,186 bytes of client source we examined. We did not run Telegram itself, so this describes the published Android client.

Does Telegram remove GPS location data from photos? On the photo path, yes, because the GPS block lives inside EXIF and EXIF cannot survive the round trip through a Bitmap. On the file path, no — our byte-for-byte comparison showed the GPS coordinates still there.

Does Telegram have an official EXIF or metadata policy? No. We read Telegram's FAQ and privacy policy directly: the word EXIF appears zero times in both. The FAQ mentions “metadata” exactly once, referring to “suggestion metadata about contacts and bots you message frequently” — the frequent-contacts feature, not photo metadata.

Does Telegram remove EXIF if I send the photo as a file? No. The file path uploads the original bytes; we measured an identical SHA-1 hash and found all 14 EXIF fields, the GPS block and the orientation tag still present, along with the XMP and IPTC blocks. This is the path where your metadata stays exposed.

Does sending a photo in higher quality preserve my EXIF data? No. Quality changes pixels, not metadata. Telegram's photo path uses quality 80 for the large size and 55 for the thumbnail, and a Live Photo still frame is re-encoded at quality 97 — and all of them end up with zero EXIF, because the metadata was already gone at the decode step. We also confirmed that carrying EXIF across the re-encode produces a pixel-identical image, so the quality setting is not the deciding factor in either direction.

Can I get my EXIF data back after sending a photo through Telegram? No. Once the file has been re-encoded, the metadata blocks are not in the delivered copy at all. If you need the original, the file still on your phone or camera has it — that is the source of truth, and you can read it with our exif viewer guide.

Does Telegram read my EXIF at all, if it discards it? Yes, exactly one field: the Orientation tag. The client reads it to display your photo upright, then encodes the picture without carrying the tag. We measured a photo with Orientation set to 6 arriving as a photo-path upload with no orientation field at all, and as a file-path upload with orientation 6 still intact.

Is there a way to send a photo through Telegram and keep its original metadata? Send it as a file. That is the only path we found that preserves the bytes, and we verified it byte-for-byte rather than taking anyone’s word for it. The trade-off is that the recipient has to download it rather than see it inline in the chat.