Does Discord Remove EXIF Data? What We Could Verify, and What We Could Not

Mostly yes for JPEG photos - and we can show exactly which part is yes. Discord's own engineering blog states that the company “has historically relied on the piexif Python library to strip EXIF data from media files.” We reproduced that exact library, on this machine, against a photo carrying 30 EXIF fields including a full GPS fix and two serial numbers. After a piexif strip: 0 EXIF fields, 0 GPS. Two things did not go away, and they matter — XMP and IPTC survived the same strip untouched, because piexif only rewrites the EXIF segment and never looks at those. We could not upload anything to Discord itself, so we label every Discord-side claim as documented rather than measured. For the mechanics of what a photo carries before it ever reaches Discord, start at do screenshots have exif data.

What we could verify, and what we could not (read this first)

Being precise about this matters more than being definitive, because the two halves of this question have very different evidence quality.

What we measured on this machine, on 2026-11-02: the stripping mechanism Discord publicly names. We installed the same library (Python piexif 1.1.3, Pillow 12.3.0, Python 3.13), built a photo with 30 known EXIF fields including GPS coordinates, ran Discord's documented strip path against it, and read the result byte by byte. Every number below came from that run.

What we did not measure: Discord's servers. We have no Discord account here and we did not upload a single file to Discord. So when we say “Discord strips EXIF,” the source is Discord's own writing and the community's download-and-inspect reports, quoted and dated below. We are not going to dress a third-party blog post up as our own test.

That distinction is not a technicality. A platform can change its pipeline without announcing it, and the community record below shows it already has — twice, in opposite directions. Treat any single community observation as a snapshot of one upload route on one date, not as a policy.

Discord's own words: two primary sources, quoted

Source 1 - Discord's engineering blog, “Modern Image Formats at Discord: Supporting WebP and AVIF” (discord.com/blog/modern-image-formats-at-discord-supporting-webp-and-avif). The relevant line is unambiguous:

“Discord has historically relied on the piexif Python library to strip EXIF data from media files.”

The same post explains why the work happens at all: “Discord must inspect, convert, and resize every still and animated image attached, and embed properly to ensure a consistent viewing experience for all users across our many platforms.” It also documents that WebP is the preferred conversion target, that AVIF is converted to WebP, that HDR AVIF is tone-mapped to SDR, and that animation status is now detected by inspecting the file rather than by trusting the extension.

Source 2 - Discord's official account, on X (x.com/discord/status/958184736874225665), replying to a user who asked directly about EXIF on 30 January 2018. The full post:

“Heya! We do strip some data (EXIF geocoding data mostly) and run the images through our resizing player to hide your IP!”

Read that sentence carefully, because the accuracy of this entire page depends on it. Discord said “mostly,” and it said “some data.” It did not say “all EXIF”. It did not say “all metadata.” It named geocoding data as the main thing stripped and mentioned resizing as a separate step. Any page claiming Discord removes everything is overstating a nine-year-old sentence that deliberately hedged.

Note also what that sentence is for: the resizing player exists to hide your IP address — the network identity of whoever uploaded the file. That is a different goal from removing photo metadata, and it is the reason Discord touches your file at all.

Our reproduction: 30 fields in, how many out?

We built a 1200×800 JPEG carrying 30 EXIF fields across three IFDs, then ran Discord's documented strip path against it. Here is the source before:

Read back through PIL.Image.getexif(), the source showed 30 fields, GPS present, and the two serial numbers intact. The file was 104,511 bytes. For the full inventory of what a camera photo carries before any platform touches it, see the field-by-field EXIF inventory.

Then we ran the strip two ways, which is where the interesting result is.

That second line is the practical one. A metadata strip does not need to touch your picture at all. We measured the same thing on the pixel level in how much space does stripping metadata save.

The gap: piexif does not touch XMP or IPTC

This is the part most pages about Discord and EXIF get wrong, and it is the part our own test caught. piexif is an EXIF library. It reads and writes the Exif\\x00\\x00 payload inside one specific JPEG segment. XMP lives in its own APP1 segment, and IPTC lives in APP13. Different containers, different rules, different libraries.

We tested exactly that, because it is easy to guess wrong in either direction:

We also confirmed the segment layout with a marker walk. Before the strip: APP0, APP1(EXIF), DQT, DQT, SOF0, DHT×4, APP1(XMP), SOS. After: APP0, DQT, DQT, SOF0, DHT×4, APP1(XMP), APP1(empty EXIF), SOS. The XMP segment did not move and did not change.

What this means for Discord. Discord has publicly named piexif as the EXIF stripper. If Discord's pipeline is that strip plus a convert/resize, then the expected result is: EXIF and GPS removed, XMP and IPTC not necessarily removed. We are stating that as an inference from the mechanism plus our measurement of the mechanism — not as a claim about what a specific Discord download contains today. The community reports in the next section are what fill that last gap.

The same distinction shows up in PNG, where there is no EXIF segment to begin with but there are text chunks (tEXt, iTXt) that hold a whole other category of data. We wrote a PNG carrying a parameters text chunk with a model name, step count and seed. PIL.Image.getexif() reported 0 fields on that PNG, while the text chunks were still there in full. This is exactly the data the AI-art community was upset about losing on Discord, and it is a different mechanism from EXIF.

The community record: what people actually found, with dates

Discord's documentation is thin on this, so the record is community reports. Here is what we found, dated, with the caveat that each is one upload route on one date.

How we sourced these, and what we could not reach. Discord's own engineering blog and its official X post were fetched directly and quoted from the page itself. The four Reddit threads below could not be fetched directly from this machine: reddit.com returns a network-security block (HTTP 403) to our requests, and the same block applies to old.reddit.com and to the JSON endpoints. We therefore took those four from indexed search-result summaries, which carry the thread title, the date, and the quoted replies — we did not read the full threads end to end. We are linking the original thread URLs anyway so you can open them yourself and check our reading, and we are telling you plainly that these four are second-hand here. Everything else on this page — the piexif reproduction, the segment walk, the byte counts, the WebP re-encode numbers — was measured on this machine and is reproduced in full.

Two independent analyses published in 2026 reach the same split: one (MetaClean, “Does Discord Remove EXIF Data? JPG Yes, PNG No (2026)”, 2 March 2026) concludes Discord strips GPS from most JPEGs while leaving PNG text chunks, video container metadata, XMP and IPTC largely alone; the other (ViewExif, “Does Discord Remove EXIF Data? Photos, Videos, and GPS Explained”) is blunter, noting that the community evidence establishes differences between JPEG, PNG and video but is not a current certification of Discord's pipeline. Both also make the point that Discord's removal is a side effect of image processing, not a published privacy policy. We think that framing is right, and it is why the practical advice at the end of this page is “check the file you actually downloaded” rather than “trust the platform.”

Why re-encoding matters even when the metadata is gone

There is a second effect on your file that has nothing to do with EXIF, and it is easy to miss because it does not show up in a metadata viewer.

We ran the full chain locally: strip the EXIF from the source photo, then convert to WebP at quality 90, which is the format Discord's blog says it prefers. Result: 0 EXIF fields, and the file shrank from 104,008 bytes to 18,052 bytes. But the pixel comparison was not clean: comparing the original 1200×800 RGB data against the WebP, the maximum per-channel difference was 17 and 1,946,517 of 2,880,000 bytes differed. That is a lossy re-encode, exactly as the community report describes.

We also measured the resize step on its own, because Discord's tweet names a “resizing player.” Resizing a 1200×800 photo down to 320×213 and writing it out as a fresh JPEG produced 0 EXIF fields — not because resizing strips metadata, but because a re-save through Pillow does not carry the EXIF block unless you explicitly ask it to. We confirmed that by re-saving with the EXIF passed through on purpose: the output then carried 10 fields and the GPS fix. Resize does not strip. The strip is a separate, deliberate step. That is a useful distinction, because it means the size and quality change you see on Discord is not the privacy mechanism — the piexif call is.

One more measurement worth reporting because it is a genuine limit of the mechanism: when we wrote the EXIF into a WebP file and then ran the piexif strip over it, the WebP still decoded cleanly and still reported 0 fields. Discord's blog says piexif's bugs used to corrupt animated WebP metadata during the EXIF removal, that this “had persisted for years, affecting every animated WebP file uploaded to Discord,” and that Discord submitted pull requests to fix piexif upstream. On piexif 1.1.3 with a static WebP we could not reproduce the corruption. That is a statement about our version and our file, not proof the class of bug is gone.

The complete field-level result table

One table, every source category, what happened to it, and how confident we are. “Measured” means we ran it here. “Documented” means Discord wrote it. “Community” means a dated public report.

Data categoryWhere it livesOutcomeEvidence
EXIF IFD0 (Make, Model, DateTime, Software, Orientation, Resolution)JPEG APP1, Exif payloadRemovedMeasured (piexif strip) + Documented (Discord blog)
Exif IFD (exposure, ISO, lens and body serial numbers, timestamps)JPEG APP1, Exif payloadRemovedMeasured (10→0 fields) + Documented
GPS IFD (lat, long, altitude, date/time)JPEG APP1, GPS IFDRemovedMeasured (31°13′2.31″N gone) + Documented (“geocoding data mostly”)
Embedded thumbnail (IFD1)JPEG APP1RemovedMeasured (segment deleted wholesale)
XMP (dc:creator, rights, edit history)Separate APP1 segmentNot removed by piexifMeasured (XMP payload still present after the strip)
IPTC (caption, keywords, credit)APP13 segmentNot removed by piexifMeasured (segment untouched)
PNG text chunks (tEXt / iTXt)PNG chunk listReported removed on Discord, result varies by routeCommunity (2023 thread, varying results)
ICC colour profileAPP2 segmentNot present in our source file; untouched by the stripMeasured (no ICC before or after)
Video container metadata (device, time, GPS in MP4/MOV)Video container atomsHistorically leaked; no current guaranteeCommunity (2020 report)
FilenameNot a metadata field at allUntouched by any metadata toolMeasured (rename it yourself)
Visible pixels (signs, reflections, windows)The image itselfUntouchedMeasured (strip is bit-identical)

Read the last three rows together. A metadata strip is not a redaction. It removes fields, not content — and the filename plus anything visible in the picture are yours to handle.

What to actually do about it

Three situations, three different answers, because the right action depends on what you are worried about.

If you are sharing a photo of your home, your car, your kid's school, or anything else with a location attached - clean it yourself, before uploading. Do not rely on Discord. The platform's own words are “mostly,” its stripping is a side effect of image processing, and the community record shows the behaviour has changed in both directions across different formats. Our own reproduction shows the one thing you can rely on: the strip removes EXIF and GPS, and leaves XMP, IPTC and your filename alone. If you want a guarantee, make the guarantee yourself.

If you are sharing AI-generated images and care about the parameters (prompt, model, seed, steps), know that the parameters usually live in PNG text chunks, not EXIF. We measured that a PNG with a parameters chunk reports 0 EXIF fields while the chunk is fully intact. That is why EXIF viewers show nothing and people still find their prompts intact - and it is why the 2023 Discord complaints were about PNG chunk loss rather than EXIF loss. Screenshot the PNG if you want to share the picture and drop the parameters deliberately, and see do screenshots have exif data for why a screenshot removes every category at once.

If you need to know what a specific Discord upload did, test it yourself on a file that does not matter. Use a synthetic photo with known tags, upload it to a private channel, download the attachment, and read the downloaded copy. Check the route you actually use - a JPEG preview, a PNG attachment and a video may not pass through the same processing. We describe the same discipline in clear metadata from photo, and the pixel-level reasoning behind why a strip is safe is in how much space does stripping metadata save.

And if you want to know what the file looks like before any platform touches it, does a screenshot of a photo keep EXIF covers the rebuild-from-scratch path, while can you recover EXIF from a screenshot covers why removed fields cannot be reconstructed afterwards.

FAQ

Does Discord remove EXIF data from photos? For JPEG photos, yes - Discord's own engineering blog says it strips EXIF using the piexif library, and its 2018 official account said it strips “EXIF geocoding data mostly.” We reproduced the piexif strip locally on a 30-field photo with GPS: 0 EXIF fields survived. We did not upload to Discord itself, so we call the platform-side behaviour documented, not measured.

Does Discord remove GPS location data? Usually, for JPEG photos. GPS lives inside the EXIF block, so a strip that removes EXIF removes the coordinates with it - we confirmed the fix was gone after the strip. Discord's own wording is “mostly,” so do not treat it as a guarantee for every format or upload route.

Does Discord remove metadata from PNG files? Different mechanism, different result. PNG has no EXIF segment; the data people mean is text chunks. The 2023 community reports say Discord stripped PNG data, with results varying by how the file was uploaded and downloaded - we read those from indexed search summaries because Reddit blocked our direct requests. We measured that those chunks are a separate container from EXIF: a PNG with a parameters chunk reports 0 EXIF fields while the chunk survives intact.

Does Discord remove XMP or IPTC metadata? We cannot confirm Discord's current behaviour, but we can tell you what its named tool does: piexif rewrites only the EXIF payload. We built a JPEG with EXIF, an XMP packet and an IPTC segment, ran the piexif strip, and XMP and IPTC were both still there. A strip aimed at EXIF does not touch them.

Does Discord strip metadata from videos? No current guarantee. A 2020 community report - which we read from an indexed search summary rather than the thread itself - found location data in downloaded phone videos, and a reply described video work as a proof of concept with no Android date. Treat video metadata as still your problem.

Does re-encoding change my image on Discord? Yes. Beyond metadata removal, Discord re-encodes and compresses. We ran the equivalent chain locally - strip, then WebP at quality 90 - and measured a maximum per-channel difference of 17, with 1,946,517 of 2,880,000 bytes differing from the original.

Does the resize step remove metadata? No. We measured resize-to-320×213 output with 0 EXIF fields, but that is because a fresh save does not carry EXIF unless you pass it through - when we did pass it through on purpose, 10 fields and the GPS fix came back. The strip is a separate, deliberate step.

Does removing EXIF hide where the photo was taken? No, not fully. EXIF and GPS go away, but the filename survives, and the picture itself still shows what is in it - street signs, house numbers, reflections, windows. For a photo you took on a phone, turn off location at the source; our turn off camera location page covers that, and find where photo was taken covers the read side.

Related reading

Next reads, depending on which part of this you need: