Does Slack Compress Images? Mine Came Back Bigger

Yes, and on my file it made things worse. Does Slack compress images? On 2026-07-18 I put a 4.13 MB iPhone photo through Slack and got back 4.58 MB, 10.9% larger than what I sent, at the same 4032x3024 pixels, with the EXIF metadata gone. Slack re-encoded my photo and the re-encode cost bytes.

Scope, stated up front because Slack has more than one image path: that is one reference file, one day, one round trip through Slack, measured on disk on both ends. It does not prove what Slack does to every image, and Slack's own documentation says different things about desktop and mobile. The transparent PNG I run through the other apps in this series was not measured on Slack, so there is no PNG result on this page. Everything below marks which part is measured and which part is documented.

Does Slack Compress Images? What One Reference Photo Did

Slack re-encoded the file and handed back 450 KB more than it received. The pixels survived intact, the metadata did not, and the byte count moved the wrong way. That combination is unusual, and only one other platform in this whole test series did the same thing.

The reference photo, and why it is the same file every time

Every app in this series meets the same photo, so the numbers line up across pages. REF-A is a real iPhone photo: 4,332,705 bytes, 4032x3024, JPEG, carrying a full EXIF block with GPS coordinates, camera model and capture timestamp. Sending one byte-identical file to a dozen different products is the only honest way to say Slack treats a photo worse than Google Drive does, because the input never varies.

The second reference file in the series, a 1240x930 PNG with a real alpha channel, was not put through Slack. I am not going to infer a PNG result from a JPEG result, so this page says nothing about what Slack does to transparency.

Bigger bytes still mean a re-encode

A file that returns 450 KB heavier has obviously been opened. Two facts prove it was not stored and handed straight back: the byte count changed, and the EXIF block my camera wrote into the original was missing from the file I downloaded. A service that keeps your bytes and returns them cannot strip metadata, because it never decoded the file. Slack decoded mine and wrote a new JPEG.

That new JPEG was written at a quality target above what my camera had already used. Re-encoding an already lossy JPEG at a higher quality setting makes the encoder spend bytes describing compression artifacts that are now baked into the image. You pay extra to preserve damage. The output is a larger file holding slightly less real detail than the input, which is the worst trade available in image handling.

What this result does not prove

The measurement store does not record which Slack client that upload went through, and it does not record whether the file I downloaded was the stored original or the display copy Slack generates for the channel. Both of those distinctions matter here more than on any other page in this series, and both get their own section below. Every app in the series gets the same treatment on the hub for which apps compress your images, including the parts each test leaves open.

Why Did Slack Give Back a File 10.9% Bigger?

Because a re-encode aimed at a quality setting instead of a size target can inflate a JPEG. Slack was not trying to hit 4.13 MB or any other number. It decoded my photo, encoded a new one at whatever quality its pipeline uses, and that quality happened to be more generous than my camera's.

Generation loss, in bytes

JPEG is lossy, which means the encoder permanently discards image information to save space and the discarded data never returns. A camera JPEG has already made that trade once. When a platform decodes and re-encodes it, quality always goes down a little, because a second lossy pass discards more, but size can move either way. The size depends entirely on the second encoder's target, not on your file. The full mechanics of that tradeoff live in the guide on lossy versus lossless compression, and MDN's image file type and format guide covers why JPEG behaves this way and PNG does not.

Slack had no size target to hit

This is the part that separates Slack from a social network. Instagram, Facebook and LinkedIn recompress hard because they are pushing your image into a feed that millions of phones will scroll, so bandwidth is their cost and shrinking your file is the whole point. Slack is a workplace file store with a chat window attached. It has no feed, no scale pressure on your one photo, and a 1 GB per-file ceiling that makes 4 MB a rounding error. Nothing in its pipeline is incentivised to make your file small.

So the byte growth is not Slack being careless, it is Slack being indifferent to size in a system where a photo going up 10% costs nobody anything. That is fine for Slack. It is worth knowing for you, because it means uploading to Slack is not a way to shrink a file, and a channel full of untouched 4 MB photos is exactly as heavy as it sounds on a phone on cellular data. If you want the photo in that channel to be small, you have to make it small before you send it.

Does Slack Compress Photos Differently on Desktop and Mobile?

Yes, and Slack has said so publicly. Does Slack compress photos the same way from a laptop and from a phone? No. Slack's own support account states that desktop uploads are not compressed, while the mobile apps compress by default through a setting you can switch off.

Desktop: Slack says it does not compress your upload

Slack's support account on X has stated plainly that uploading images on desktop does not compress them, and that mobile compression is enabled by default with a setting to disable it (@SlackHQ). An older post from the same account puts the same thing another way: Slack does not compress file or image uploads from desktop, although it does cut thumbnails at various sizes to display inside the app. Hold on to that second half. It is the sentence that explains my measurement, and it is the sentence every competing page leaves out.

Mobile: Optimize images for upload is on by default

On iOS and Android, Slack ships with a setting called Optimize images for upload turned on. It compresses the image on the device before anything is sent, which is why mobile uploads are faster and lighter on cellular data, and why a photo you send from your phone can look softer in the channel than the same photo sent from your laptop. Turning it off sends full resolution and costs you upload time and mobile data.

One caveat that trips people up: the setting lives on the sending device. If a colleague sends you a photo from their phone with optimization on, switching your own setting off changes nothing about the file you receive. The image was already compressed before it left their handset.

How to turn off image compression in Slack on iPhone and Android

Open Slack on the phone, tap your profile picture, then Preferences, then Advanced, and switch off Optimize images for upload. The wording and the exact path shift between app versions and between iOS and Android, so look for the Advanced section rather than a fixed menu position. Do it before you send, not after, because it only affects future uploads.

The Inline Preview Is Not the File Slack Stores

Slack keeps two versions of your image, and almost every page about this question talks about only one of them. There is the file object Slack stores, and there is the smaller display asset Slack renders inside the channel. They are different bytes, and which one you are looking at decides whether you think Slack wrecked your photo.

The stored original and the 1 GB ceiling

Slack accepts files up to 1 GB per upload on every plan from Free through Enterprise Grid, and the uploaded file is stored as an object you can download or pull back through the API (Slack Help: add files to Slack, and the files.upload method in Slack's developer docs). Plan tier changes your storage and history, not the compression behaviour. The common complaint that a paid workspace protects your image quality does not hold up: everyone is on the same 1 GB rule.

The 25,000 pixel and 45 million pixel preview ceiling

Slack only renders an image inline if it is under 25,000 pixels on its longest side and under 45 million pixels in total. Above either threshold the file still uploads fine, it just shows as a download link instead of a picture in the conversation. My photo is 4032x3024, which is 12.2 million pixels, comfortably inside both limits, so it got a real inline preview.

Which one did my test measure?

I cannot tell you, and I am not going to guess. What I can tell you is what each branch would mean. If the 4.58 MB file I downloaded was the stored original, then Slack's statement that it does not compress desktop uploads is true about size and misleading about handling, because the bytes changed and the metadata was removed. If it was a display copy, then the practical warning is sharper: what comes back out of a Slack link is not what you put in, and anyone who saves an image from a channel is saving Slack's version of it.

Either branch lands on the same advice. Do not treat Slack as the archive copy of anything, and do not judge an image by the preview in the channel. That preview-versus-original split is the piece no page currently ranking for this question separates, and it is why the answers you find elsewhere contradict each other.

What Is the Slack Image Size Limit?

One gigabyte per file, on every plan. The slack image size limit that actually affects your images day to day is not that ceiling, it is the pixel thresholds that decide whether your image appears in the conversation at all.

The gap between 1 GB and 45 million pixels is where people get confused. A huge panorama or a stitched scan can be well under 1 GB and still refuse to display inline, because the constraint that failed was pixel count, not file size. Nothing in the interface explains which limit you crossed.

What Slack Changes: File Size, Dimensions, Format, and EXIF

Slack changed two of the four properties: the file grew 10.9% and the EXIF metadata was removed, while the pixel dimensions and the JPEG format came back untouched.

Dimensions survive, which is genuinely good

Slack kept all 12.2 megapixels. That puts it far ahead of the platforms in this series that quietly resize: LinkedIn cut the same photo to 480x360, Facebook took it to 2048x1536, and Google Slides landed on 2048x1536. If someone needs to open your screenshot and read small text in it, Slack will not have thrown away the pixels that carry the text.

Animated GIFs go through the same preview machinery

I did not measure a GIF, so there is no number here, and I will not borrow one. What is documented is that Slack generates display assets for animated files the same way it does for stills, and several third-party write-ups report reduced quality or frame rate in the version that plays inside a channel. The uploaded file itself is still stored and downloadable under the same 1 GB rule. If frame-accurate playback matters, hand people the download rather than the thing looping in the conversation.

EXIF is stripped, and that is a real privacy default

The metadata block your camera writes carries GPS coordinates, camera model and the exact second of capture. It was in the file I uploaded and gone from the file I got back. For a workplace tool that is sensible, since photos land in channels that outlive the conversation, and stripping location data from a phone photo before a hundred colleagues can download it is the right call. It also means Slack is not where you verify whether metadata survived a workflow, because it will not have. Our own compressor takes the same position and strips EXIF by default rather than hiding it behind a checkbox.

How to Send High Resolution Images in Slack

Upload from desktop, switch the mobile optimization setting off, post the file as an attachment rather than an inline paste, and size it yourself before you send. That is how to send high resolution images in Slack, given that the platform will re-encode something no matter what you do.

1. Upload from desktop when quality is the point

Slack states it does not compress desktop uploads, and the mobile client compresses by default. If a designer needs the real pixels, send it from the laptop. That single choice removes the client-side compression pass entirely and it costs you nothing.

2. Switch off the mobile optimization setting when you must send from a phone

Preferences, then Advanced, then Optimize images for upload off. Remember it applies to your sends only, so if you are the one receiving a soft image, the person who sent it has to change their setting, not you.

3. Post it as a file, not as an inline paste

Attaching the file rather than pasting the image into the message box makes it obvious to everyone in the channel that there is an original to download, and it keeps the conversation pointing at the stored object rather than at the display copy. Anyone who needs the real thing clicks Download instead of right-clicking the preview.

4. Decide the size yourself before Slack does

The reliable version of all of this is to control the file before it goes anywhere. Choosing quality 80 yourself is a decision you can inspect and reverse. Letting a platform re-encode at a setting you cannot see, and possibly hand you a file 10.9% bigger, is not a decision at all. The same logic applies when you are compressing images for email, where the size ceiling is far less forgiving than Slack's.

How Slack Compares to the Other Work Tools I Measured

Slack is the only tool on this chart that gave the photo back heavier than it received it. Same 4.13 MB file, same day, eight products people use at work, each number measured on disk after a full round trip.

The pattern is not gentle tools versus rough tools, it is storage versus delivery. The products that exist to hold your file gave it back untouched or close to it: Word left it byte identical, so did Dropbox and Google Drive. The products that render your image into a layout for someone else took large bites out of it. Slack sits awkwardly between the two, storing the file properly while generating a display copy, and my measurement is what that middle position costs. Microsoft Teams, the closest comparison of all, did the same job and came back 5.7% smaller instead.

Decide the Size Before Slack Does

Slack is one of the few places a photo can come back heavier than it went in, and there is no setting anywhere in the product that prevents it. What you control is what you hand over.

Compress the photo first, at quality 80, and a typical phone photo comes back 60 to 80% smaller with nothing visible lost, which means the version living in that channel forever is the one you chose. It strips the EXIF block before anyone in the workspace can read it, and takes thirty images at a time up to 25 MB each, free, with no signup. Does Slack compress images in a way you can predict? Not reliably. Do it yourself and the answer stops mattering. The full method is in the main guide on how to compress images.