Does Twitter Compress Images? Yes, and X Keeps Two Copies

Yes, but there are two answers because X keeps two copies. Does Twitter compress images? On 2026-07-18 I posted a 4.13 MB iPhone photo, 4032x3024 pixels, to X. The stored full resolution copy came back 3.78 MB, only 8.5 percent smaller. The copy X actually serves into timelines was cut to 2048x1536 and 802,715 bytes, roughly 81.5 percent smaller.

Scope before anything else, because honest numbers need it. These results are what X did to two reference files, on one day, through one upload path, captured from the copies X kept at that moment. A different client, surface, or account setting can behave differently, and this page keeps measured results and documented claims clearly separated.

Does Twitter Compress Images? The Measured Answer

Yes. X re-encoded my photo, stripped its metadata, and built a much smaller copy for timelines, and no setting fully prevents any of that. What makes X unusual is that the answer splits in two: the copy X archives barely changes, while the copy people actually see loses more than four fifths of its bytes.

The reference files behind every number

Every platform in this test series gets the same two files. REF-A is a real iPhone photo: 4,332,705 bytes, 4032x3024 pixels, a JPEG still carrying the full EXIF block a phone camera writes, GPS coordinates included. REF-B is a photographic cutout with real transparency: 1,863,465 bytes, 1240x930 pixels, an RGBA PNG. Feeding identical inputs to every app is what makes the full app-by-app scoreboard comparable. On 2026-07-18 I posted both files to X and captured what came back.

What X handed back

REF-A came back twice. The stored copy, name=orig in X's image URLs, stayed 4032x3024 and dropped only 8.5 percent, from 4.13 MB to 3.78 MB, with every EXIF field stripped. The timeline copy, name=large, was resized to 2048x1536 and re-encoded down to 802,715 bytes, roughly 81.5 percent smaller than my upload. REF-B came back changed in kind, not just in size: X converted the transparent PNG to an opaque JPEG at the same 1240x930 pixels, 91.2 percent smaller.

What one test can and cannot prove

It proves what it measured: on this date, through the standard post path, X kept a near-full-quality archive copy, served a heavily reduced one, converted my transparent PNG to JPEG, and stripped EXIF from the stored photo. It cannot prove that every client, account, and setting gets identical treatment, and my notes for this test record the files rather than the posting client. Where a claim on this page rests on documentation instead of my own capture, I say so.

Which Copy of Your Photo Do People Actually See?

The small one. Feeds load the timeline copy, and on my test that copy was 2048x1536 at 802,715 bytes, which is 18.5 percent of the original's bytes and 25.8 percent of its pixels. When people search does X compress images after watching a crisp photo turn soft the moment it posts, this copy is nearly always the one they are reacting to.

One upload, two files

X's image CDN keeps each photo in several named sizes. The feed pulls the downsized name=large rendition, while a higher resolution copy can be reached by opening the image directly, though X does not guarantee it for every photo. The split has history: reporting in 2019, based on statements from Twitter's own engineers, described a change that stopped re-compressing the uploaded JPEG on arrival and instead preserved the uploader's encoding where possible, re-encoding only the smaller display copy. Seven years later my numbers still match that design, an archive almost untouched at 8.5 percent smaller, a rebuilt preview 81.5 percent smaller.

The measured gap between the two copies

The stored copy kept 91.5 percent of its bytes; the timeline copy kept 18.5 percent. That gap is the single most useful thing to know about images on X. Complaints about X ruining photos and reassurances that X barely touches them are both right, they are just describing different files.

What Are X's Image Size Limits Right Now?

Five megabytes per photo and up to four photos per post, with viewable resolution reaching 4096x4096 in the best case. X's developer media guidelines put the hard caps at 5 MB per image and 15 MB for a GIF on the web, and X recommends 1200x675 or 1080x1080 for post images, a display suggestion rather than a limit.

Search for the Twitter image size limit and you will find numbers from every era still ranking, because the ceilings have moved. Reporting in 2019 described the viewable cap rising from 4 megapixels to 16 megapixels on web, iPad, and Mac, while the Android and iOS apps historically topped out at 2048x2048. Today, practitioner walkthroughs document downloads up to 4096x4096 when the high quality uploads setting is on, a ceiling X has never formally published, so treat it as observed rather than promised.

Profile media has its own lane: X's help pages specify a 2 MB profile photo at a recommended 400x400 and a 1500x500 header, though sources disagree slightly on the header's exact byte cap. The 5 MB post limit is generous, but a modern phone photo can still clear it, and an oversized upload just hands X's pipeline more work. If a photo is bumping the limit, compress it below 5 MB in your browser first; at quality 80 a phone photo typically comes back 60 to 80 percent smaller with no visible difference, and you choose that tradeoff instead of X choosing it for you.

What Does X Actually Do to an Uploaded Image?

Four things, in order: it identifies the format and may convert it, downscales anything over its ceilings, re-encodes with lossy settings, and strips metadata. Each stage is worth understanding, because each one is a separate way your photo changes.

1. Format decision. JPEGs stay JPEG. PNGs are evaluated and often converted to JPEG, the full rules are in the next section. WebP is accepted for upload but converted, and animated GIFs are transcoded to MP4 for playback while the original GIF stays downloadable.
2. Downscaling. Images over the display ceilings are resized. My photo kept its 4032x3024 pixels in storage but was cut to 2048x1536 for the timeline rendition.
3. Lossy re-encode. Official engineering communication from 2018 and 2019 put the JPEG target at roughly 85 percent JFIF quality, with one older third-party estimate closer to 80; the exact figure is platform-set, approximate, and not adjustable by you. Re-encoding discards color detail first through chroma subsampling, which averages color across neighboring pixels because your eye notices brightness more than hue. Stacked lossy passes compound, a one way street our lossy vs lossless guide walks through.
4. Metadata stripping. The public copy sheds its EXIF block, measured directly in my test and covered in its own section below.

How current are these rules?

Here is the honest caveat almost no guide states: nearly every technical specific in circulation, the 85 percent quality target, the PNG rules, the resolution ceilings, traces back to official Twitter engineering communication from 2018 and 2019. X has published nothing comparably specific since the rebrand, so current behavior is inferred continuity, not freshly documented fact. My 2026 measurement matching the 2019 design is the strongest evidence I can offer that the old rules still describe the pipeline.

Does Twitter Compress Photos and Graphics the Same Way?

No. Photos stay JPEG and get re-encoded toward X's quality target, while graphics uploaded as large full color PNGs are usually converted to JPEG outright, the most destructive thing X does to any file. Which path your upload takes depends on format, size, and color depth.

The PNG rules have a primary source: the Twitter engineer responsible for the 2019 pipeline explained that PNG-8 images are kept and recompressed losslessly, and larger PNGs survive as PNG mainly when they stay small, with roughly 900 pixels on the longest side as the stated line. It is an engineering heuristic, not a promise; X weighs whether keeping PNG costs more bytes than converting, per image. For the decision on your side of the upload, PNG vs JPG is its own guide, but the X-specific summary is short: photographs should arrive as JPEG, because a photographic PNG is large for no visible benefit and gets converted anyway, at X's settings instead of yours.

Did Transparency Survive the PNG Upload?

No. My transparent PNG came back as an opaque JPEG, alpha flattened onto a background, at 8.8 percent of its original bytes. REF-B went in as a 1,863,465 byte RGBA PNG at 1240x930 and came back as a 160.6 KB JPEG at the same 1240x930, a 91.2 percent reduction and a complete format change. X also kept no secret original this time: the stored and timeline copies were byte identical for this file. Transparency is part of PNG's specification, the alpha channel is defined in the W3C PNG standard, and JPEG has no equivalent, so the conversion had no way to preserve it.

Precision matters about what this proves. The 2019 rule predicts that a full color PNG above roughly 900 pixels gets converted; REF-B is 1240x930 at full color depth, above that line, and it was indeed converted. My result is consistent with the rule for one file at one size. It does not map the threshold itself, because I tested one size rather than a ladder of them, so treat 900 pixels as the best documented line, not a number I have verified.

Does the transparent pixel trick still work?

Treat it with suspicion. The famous trick, save as PNG and add a single transparent pixel to force lossless handling, comes from a 2018 blog post and a pair of 2020 tweets, and Google's AI Overview still repeats it on this query as if it were settled fact. My test is a caution: a PNG with real transparency, far more than one transparent pixel, was converted to JPEG anyway at 1240 pixels wide. Transparency alone protects nothing. The mechanism that earned the trick its reputation is the small-or-PNG-8 rule above, and a transparent pixel is redundant on a file that already fits that rule. I did not test the one pixel variant at small sizes, so I will not claim it never works, only that its premise failed at this size and color depth. If transparency matters to your work, compress the PNG without losing transparency for channels that respect alpha, and treat X as a JPEG delivery service.

Does the Result Change on Web, iPhone, Android, or in a DM?

Historically yes by client, and the DM path is the least documented corner of X's pipeline. My measurement covers the standard post path; here is where the record is solid and where it is thin.

Web vs the mobile apps

The 2019-era reporting that raised the viewable cap to 16 megapixels applied it to web, iPad, and Mac, while the Android and iOS apps historically capped at 2048x2048, and PNG upload support was originally web only. Client gaps like these narrow over time, but X has never published a current per-client matrix, so assume the web uploader is the most capable path until X documents otherwise.

The high quality image uploads setting

Buried in the mobile apps under data usage settings, high quality image uploads governs the resolution your phone sends and stores, up to the observed 4096x4096 ceiling. It is worth switching on if you post photos from mobile. It is also widely misread: the setting raises what gets stored, it does not switch off server-side re-encoding, and there is no toggle anywhere on X that does.

Public post vs DM, and what Premium changes

My test used a public post. DM attachment handling is inconsistently documented, and community reports suggest DMs can retain more metadata than public posts, so I make no measured claim there and neither should anyone else currently ranking for this query. Premium is documented for video, quality selection and HD uploads are tied to the subscription in X's own communication, but no official source confirms Premium changes image re-encoding at all. Until X says otherwise, assume your photos get the same pipeline at every tier.

What Happens to EXIF and GPS Data on X?

It is stripped, and unlike much of this topic, that is measured: the stored copy of my photo came back with every EXIF field removed. EXIF data, the hidden metadata block your camera writes into each file, includes GPS coordinates, camera model, lens settings, and timestamps, and X's public copies do not carry it. The timeline rendition is derived from that stripped copy, so it has nothing to inherit.

For most people this is quietly protective, posting a photo should not broadcast where you took it. For photographers it cuts the other way: copyright and licensing fields embedded in EXIF vanish too, with no opt out. And per the section above, do not assume DMs behave identically; if metadata privacy matters, strip it yourself before the file leaves your machine rather than trusting any platform's pipeline.

How Does X Compare to Other Platforms?

Measured against the same photo, X's timeline copy sits between Bluesky and Facebook in severity, while X's stored copy is the second gentlest result in the entire series. People asking does twitter compress images usually mean compared to the alternatives, and the only fair comparison runs the same file through all of them.

The Facebook row is the sharpest comparison: Facebook delivered the identical 2048x1536 shape but squeezed it to 579.7 KB, where X's timeline copy spent 802,715 bytes, about 200 KB more for the same pixels. And X is the only platform in the series that exposes both a heavily processed copy and a nearly untouched one for the same post, which is why the question has two answers here and one answer everywhere else.

How to Post Photos on X With the Least Quality Loss

Give the pipeline a file it has almost nothing left to do to. Five steps, in order of impact.

1. Post photographs as JPEG at quality 80 to 85. Quality 80 is the setting we treat as visually lossless for photographs. A file already near X's quality target gives the re-encoder little to remove, which is what limits double-compression artifacts; what compression actually does to quality shows the evidence side by side.
2. Mind the long edge. Timelines got 2048 pixels in my test no matter what was stored. If feed sharpness is the goal, reduce the resolution yourself with a proper downscaler before posting, so the feed copy is resized once, by a tool you chose, instead of twice.
3. Keep graphics small and shallow. Text, logos, and line art survive best as PNG-8 or under roughly 900 pixels on the longest side, per the 2019 engineering rule. A large full color PNG becomes a JPEG with artifacts exactly where flat graphics show them worst.
4. Switch on high quality image uploads on mobile. It raises the stored resolution toward the 4096x4096 ceiling and costs nothing but data.
5. Tell viewers to expand when detail is the point. The feed shows the gutted copy; the tap-through shows the archive. For photography threads, that one habit changes what your audience actually sees.

Send X a Photo Its Pipeline Can Barely Touch

X will keep two copies of whatever you post: an archive almost nobody opens and a timeline copy cut to less than a fifth of your bytes. You cannot veto either one, but you decide what they start from. Compress the photo in your browser at quality 80, watch it land under X's 5 MB cap at a size you chose, and post that file. It is free, it runs on open source encoders, files delete within an hour, and EXIF is stripped on your terms before X ever sees the photo. The timeline copy will still be small, but it will be a small copy of your best file, not of whatever survived a pipeline you never got a vote in.