Telegram: “photo” and “file” are different privacy questions
Send the same JPEG as a photo and as a file, then download both and compare the hashes. A file send can keep the original bytes, including EXIF.
Does a Telegram file send keep more metadata than a photo send?
Send the same JPEG as a Telegram photo and as a file, then download both and compare hashes. A file send can keep the original bytes, including EXIF. If the photo copy changes and the file copy matches the source hash, that test kept the file. Keeping the original can also keep metadata you did not intend to share.
| Result | What it suggests |
|---|---|
| Photo changes; file is byte-identical | The media path transformed the image while the file path preserved the source in that test. |
| Both change | Both routes produced a different delivered artifact. Compare the diffs rather than assuming the cause. |
| Both are identical | That client/version/test preserved the bytes on both routes. Repeat after meaningful app changes if this matters operationally. |
Last updated
Compare photo send and file send
Telegram has more than one way to send media. Treat “send as photo” and “send as file” as separate cases instead of one rule about Telegram and EXIF.
Use the same source image for both tests. Send one copy through the normal photo picker and one through the file/document route. Download both on the receiving side and compare them with the original.
Your source file can be hashed and inspected before it leaves your device.
The two received files can be compared for bytes, dimensions, encoding, and metadata.
A clean delivered copy does not reveal every intermediate copy Telegram may have processed.
Run the comparison
- Pick a JPEG with a few harmless but easy-to-recognize metadata fields.
- Record SHA-256, dimensions, byte size, EXIF/XMP/IPTC, and ICC profile.
- Send it as a photo.
- Send the same source as a file/document.
- Download both results from a second account or device and inspect them.
Three outcomes that mean different things
| Result | What it suggests |
|---|---|
| Photo changes; file is byte-identical | The media path transformed the image while the file path preserved the source in that test. |
| Both change | Both routes produced a different delivered artifact. Compare the diffs rather than assuming the cause. |
| Both are identical | That client/version/test preserved the bytes on both routes. Repeat after meaningful app changes if this matters operationally. |
Why “send as file” can be worse for privacy
People sometimes choose a file route because they want maximum quality. If that route preserves the original file, it may also preserve metadata you did not intend to share. Quality preservation and privacy cleanup are different goals.
What the download can tell you
A recipient-side download shows what the other person received. If location or device fields are sensitive, remove them before you send, especially on the file/document route, which can keep more of the original.
Preserve quality without forwarding your history
Use CreatorPrivacyKit to inspect the source and create a cleaner sharing copy locally.
Inspect a file →A local file copy and a canvas JPEG, 27 October 2026
On 27 October 2026 this site built one JPEG with Pillow 10.2.0, RGB, 960 by 640, quality 90, then wrote tags with ExifTool 12.76. The file is 15040 bytes, SHA-256 f849b4a5b37a3179e093bda7c3adbee793fd485c436eb90c5e548c5aa5e9f1f0. The tags are Make CreatorPrivacyKit, Model SyntheticFixture, LensModel FixtureLens, DateTimeOriginal 2026:10:27 12:00:00, Artist CPK Fixture, ImageDescription 2026-10-27 telegram file fixture, Copyright Fixture only, GPS 35 deg 0' 0.00" N, 139 deg 0' 0.00" E, altitude 12 m above sea level, and GPSVersionID 2.3.0.0. XMP-dc:Description is synthetic fixture, not a residence. IPTC Keywords is fixture. ColorSpace is Uncalibrated. There is no ICC profile. The coordinates were typed. They are not a residence and they did not come from a GPS receiver. The file was not uploaded. Pillow decoded the source to RGB with SHA-256 5582955b5c2227adbff6c454929422538e7a45ae30746b74c50d1b4ac378b263.
A byte copy of that file has the same 15040 bytes and the same SHA-256. A second copy was opened in headless Chrome 154.0.8037.92 with --headless=new, --no-sandbox, --disable-dev-shm-usage, and --disable-gpu. The page called createImageBitmap, getContext("2d", { alpha: true }), and toBlob("image/jpeg", 0.95). Those are the JPEG steps in sanitizeImage. The bundled function was not called, and no button on this site was clicked. The canvas file is 5342 bytes, SHA-256 e9bfaa3d9f0954bcbc4face54d5edb90783559829b2eb1539c4de4ea8d670813, still 960 by 640. Pillow decoded RGB SHA-256 d561f799646ce8c3882699971a9b005d7ac019b0450244c41eb8fbc8ddb07049, which differs from the source. An ICC profile is present, 456 bytes. ExifTool lists JFIF 1.01 and no Make, Model, GPS, XMP, IPTC, description, or keywords. ProfileDescription is sRGB. ProfileCopyright is Google Inc. 2016. ProfileVersion is 4.3.0. ProfileDateTime is 2016:01:01 00:00:00.
This run did not open Telegram. A file attachment that keeps the original bytes would still have the source hash. A photo path that rebuilds a JPEG can look like the canvas copy: a new hash, the camera and GPS tags gone, and an sRGB profile whose copyright line reads Google Inc. 2016. Only a file downloaded from the app shows which path that client used. The 2 GB and 4 GB Premium figures already cited from Telegram’s FAQ were not re-checked on 27 October 2026. A page that states the photo-versus-file rule without a source hash, a byte-identical local copy, and a canvas rebuild is not a substitute for the table below.
Did this run send the JPEG through Telegram?
No. Telegram was not opened. The 15040-byte source and the byte copy share SHA-256 f849b4a5b37a3179e093bda7c3adbee793fd485c436eb90c5e548c5aa5e9f1f0. The canvas JPEG is 5342 bytes. A file downloaded from the app is what shows which path a client used.