Yes, but not the way people assume. Does Microsoft Teams compress images? I ran the test on 2026-07-18: a 4.13 MB iPhone photo went into Teams and came back at 3.90 MB, 5.7% smaller, still the full 4032x3024 pixels, with the EXIF metadata removed. Teams shaved bytes and metadata, not resolution. The blur people complain about comes from a different part of the product.
| Teams upload test, 2026-07-18 | Uploaded | Served back |
|---|---|---|
| File size | 4.13 MB | 3.90 MB, 5.7% smaller |
| Pixel dimensions | 4032x3024 | 4032x3024, kept |
| Format | JPEG | JPEG, no conversion |
| EXIF metadata | present | stripped |
Scope first, because Teams has more image paths than almost any product in this series: that is one reference file, one day, one round trip, measured on disk on both ends. The transparent PNG I run through other platforms was not measured on Teams, so this page makes no claim about PNGs or transparency. And the measurement store does not record which Teams client or send method carried the upload, which matters here, so the sections below are explicit about what is measured and what is documented.
Does Microsoft Teams Compress Images? Here Is the Measurement
Teams re-encoded my photo lightly: 0.23 MB of bytes gone, every pixel kept, metadata removed. On the scale this test series uses, that is one of the gentlest results any messaging tool produced, and it is nothing like the wrecked screenshots that send people searching for this question.
The reference photo, identical for every platform
The file is REF-A, the same reference photo every product in this whole app compression series receives: a real iPhone photo, 4,332,705 bytes, 4032x3024, JPEG, with a full EXIF block carrying GPS coordinates, camera model and timestamp. One unchanging input is what makes a claim like "Teams is gentler than Slack" a measurement instead of an opinion.
A smaller file with missing metadata means a re-encode
The file I downloaded was not the file I uploaded. Two changes prove Teams opened it: the byte count dropped by roughly a quarter of a megabyte, and the EXIF block my camera wrote was gone from the copy I got back. A service that stores your bytes and returns them untouched can do neither, because it never decodes the file. Teams decoded mine, discarded the metadata, and wrote a new JPEG. The pixels that survived are all there, but they have been through a second lossy encoder pass.
What this one number cannot tell you
The measured store records the result, not the route. It does not say whether that upload was pasted or attached, or whether the 3.90 MB file is the stored original or the copy Teams serves back through its chat interface. I am not going to guess. What I can do is lay out the two documented pipelines below, because the honest answer to this question is that the route your photo takes decides what happens to it.
The Two Pipelines: Paste It In or Attach It as a File
Teams treats a pasted image and an attached image as different objects in different storage systems. Pasting embeds the image in the chat infrastructure and shows everyone a compressed preview. Attaching uploads the original bytes to OneDrive or SharePoint and keeps them intact. Most quality complaints trace back to not knowing which of the two just happened.
Pasting puts your photo in the chat, not in your files
Paste a screenshot from the clipboard and it lives inside the conversation thread, not in any document library. Teams renders a compressed thumbnail for display, and that thumbnail is what most people then interact with. It never appears in the Files tab, and there is no pristine original sitting behind it that you can dig out later.
Attaching sends the original to OneDrive or SharePoint
Use the attach button instead and the file itself is uploaded: to the sender's OneDrive for 1:1 and group chats, or to the team's SharePoint library for channel posts. Microsoft's own Q&A confirms that files shared this way are stored in SharePoint or OneDrive and are not compressed by Teams; the limits that apply are those services' limits, up to 250 GB per file (Microsoft Q&A on Teams file compression). The chat still shows a compressed preview, but a full-quality source exists and the Download button reaches it.
Where my 3.90 MB sits between those two stories
A 5.7% trim with EXIF stripped matches neither extreme: it is not the byte-identical original the attachment path promises, and it is nowhere near thumbnail territory. The copy Teams handed back had been through its image pipeline, gently. That gap between what the documentation describes and what a real download measures is exactly why this series measures instead of quoting, and it is the number no page ranking for this question currently has.
Why Does Teams Compress Photos in the First Place?
Because every image in a conversation needs a display copy, and display copies are built for scrolling, not archiving. A channel where hundreds of screenshots load at full camera resolution would be unusable on a laptop and hostile on a phone plan, so Teams generates compressed previews for the conversation view and keeps heavyweight originals, where they exist, in storage.
The preview in the chat is never the original
What renders inline is a thumbnail Teams generated, regardless of how the image arrived. Judging image quality by what you see in the conversation is judging the preview, and saving that preview gives you preview quality. This single distinction explains most "Teams ruined my image" reports.
The viewer and the download can disagree
Users on Microsoft's forums report a stranger case: the image looks sharp when clicked open in the Teams viewer, then degrades on download. The explanation given in a Microsoft Q&A thread is that the viewer can stream a higher-quality representation while the download delivers a separately stored, compressed derivative. The behavior is inconsistently documented and seems to vary by client version, which is its own kind of warning: treat what Teams shows you and what Teams gives you as two different files. The mechanics of why every lossy re-encode costs detail are covered in our guide to lossy versus lossless compression.
Drag and drop hands you the thumbnail
Dragging an image out of a Teams window onto your desktop saves the compressed display copy under a renamed file, not the original. If an original exists, the route to it is the Download button in the expanded image view, or the file's location in OneDrive or SharePoint. Users have documented this trap since 2019, and it still applied after the new Teams client shipped.
Can You Turn Off Image Compression in Teams?
On the desktop and web clients, no. There is no setting anywhere in Teams for Windows, Mac or the browser that disables image compression, a point confirmed by university IT documentation that calls it not a feature that can be disabled (Grand Valley State University IT knowledge base). The mobile apps are the exception: they expose a real quality control.
The mobile Image Upload Quality setting
On iOS and Android, open Settings, then Data and Storage, then Image Upload Quality. Four options control what leaves your phone:
| Setting | What it does |
|---|---|
| Automatic | full quality on strong connections, may downgrade on weak ones |
| Always Send Full Size | no reduction applied before upload |
| Always Send in High Resolution | high-resolution version, not guaranteed original bytes |
| Always Send in Low Resolution | reduced image, saves mobile data |
The setting acts on the sending device. If a colleague's phone is on Low Resolution, nothing on your end recovers the detail their app already discarded before upload.
The Office compression toggle does not exist here
Microsoft's well-known "turn off picture compression" checkbox covers Word, PowerPoint, Excel and Outlook. Teams is not on that list, and no equivalent checkbox exists in any Teams client. Searchers land on that Office documentation constantly while trying to fix Teams, which is how the myth of a hidden desktop toggle keeps circulating. On a desktop, the only quality decision you actually own happens before upload: compress the photo to the file size the conversation needs, and Teams has less reason to touch it.
What Does Teams Do to EXIF Metadata Now?
Since early 2026, Teams strips EXIF metadata from images uploaded directly into chats and channels, by default, with no admin control to disable it. My test confirms it in practice: the GPS coordinates, camera model and timestamp present in the uploaded file were gone from the copy Teams served back.
What gets stripped, and what keeps its metadata
The stripping applies to the direct-upload path, and a first-hand test by a Microsoft 365 engineer documented the boundaries shortly after rollout (Topedia's EXIF removal test):
| Path | EXIF outcome |
|---|---|
| Direct upload to a chat or channel | stripped from what recipients get |
| Image shared as an OneDrive link | kept |
| File opened from the SharePoint library | kept |
| Videos | not covered, metadata kept |
| Your own local original | untouched |
Why this is the right default for a workplace
A phone photo posted to a channel outlives the conversation, and its EXIF block can place a person at an address at a time. Removing that before a hundred coworkers can download it is a sensible default, and it is the same position our compressor takes: metadata comes off unless you have a reason to keep it. The flip side matters too. If your workflow needs EXIF to survive, capture times for an insurance claim, GPS for a site survey, the direct-upload path destroys it, and the OneDrive link path is the one that preserves it.
Teams Image Limits by Surface, in One Table
The file-size ceiling in Teams is really a SharePoint ceiling, and it is so high it will never be your problem. The limits that actually shape your images are per surface (Microsoft Teams limits and specifications):
| Surface | Limit |
|---|---|
| File uploaded to a chat or channel | 250 GB per file |
| Bot and card inline images | 1024x1024 px, 1 MB, PNG/JPEG/GIF only |
| Custom meeting background | 5 MB, JPG or PNG, 1920x1080 recommended |
| Profile photo | 4 MB, 648x648 px recommended |
| Channel email attachments | under 10 MB each, max 50 inline images |
Why profile photos come back blurry
Profile photos go through a separate pipeline that re-encodes every upload into fixed size tiers, from 48x48 up to 648x648 pixels, the discrete sizes Microsoft Graph serves (profilePhoto resource documentation). Upload anything smaller than 648x648 and Teams upscales it into blur at the larger tiers. Upload at exactly 648x648 or larger, and use PNG if the photo contains text or hard edges, because the re-encode is kinder to it.
How to Send Full Size Photos in Teams
Attach the file instead of pasting it, or share an OneDrive link and have the recipient click View original. Those are the two reliable ways to send full size photos in Teams, and most advice about how to improve image quality in Teams reduces to picking one of them deliberately.
Method 1: attach, do not paste
Click the attach button and pick the file, rather than pasting the image into the compose box. The original bytes land in OneDrive or SharePoint, and anyone who needs real quality clicks Download in the expanded view instead of saving the inline preview. This costs nothing and fixes the most common mistake.
Method 2: the OneDrive link and View original
Upload the image to OneDrive yourself, share the link in the chat, and tell the recipient to click View original in the preview. This is the method the GVSU knowledge base cited above documents as the way to preserve original quality end to end. One tradeoff to choose consciously: the OneDrive path also preserves EXIF metadata, including GPS, which the direct-upload path would have stripped. Full fidelity means full metadata.
Method 3: set the phone to Always Send Full Size
If your uploads come from mobile, the Image Upload Quality setting decides quality before Teams infrastructure ever sees the file. Always Send Full Size sends what your camera made, at the price of slower uploads and more mobile data. Automatic is the default, and on a weak connection it will quietly choose data savings over your pixels.
When full size is the wrong goal
A 12-megapixel photo attached to make one quick point spends everyone's bandwidth on detail nobody will zoom into, and a channel accumulates those forever. If the image is a visual reference rather than a deliverable, a compressed copy that loads instantly serves the conversation better than an original that ships 4 MB per viewer. Decide by what the recipient will do with it, not by reflex.
How Teams Compares to the Rest of Microsoft, and to Slack
Microsoft does not have one image policy, it has one per product. On the same day, with the same photo, Word and an Outlook attachment returned the file byte identical, Teams trimmed 5.7%, and Outlook's paste-inline path cut 80.6% and resized. Slack, the product Teams gets compared to most, went the other direction entirely.
| Upload path | Served back | Change | Dimensions |
|---|---|---|---|
| Slack | 4.58 MB | 10.9% LARGER | kept 4032x3024 |
| Microsoft Word | 4.13 MB | byte identical | kept 4032x3024 |
| Outlook, attached | 4.13 MB | byte identical | kept 4032x3024 |
| Teams, my upload | 3.90 MB | 5.7% smaller | kept 4032x3024 |
| Outlook, pasted inline | 0.80 MB | 80.6% smaller | resized to 1920x1440 |
The pattern is the surface, not the company
Read down that table and the split is between surfaces that store and surfaces that display. Word embedded the photo byte for byte, and Outlook's attachment path did the same, because both are handing a file onward. The paths that render your image into a conversation or a message body, Teams chat and Outlook inline, are the ones that spent bytes. Teams spent very few of them; Outlook inline spent almost all of them.
Against the other chat apps
Among messaging tools, Teams sits at the careful end. Slack served the same photo back 10.9% larger after its re-encode, Discord shaved a token 0.3%, and WhatsApp's send-as-document path returned it byte identical, though its regular photo path was not measured. Of those, Teams and Slack both stripped the metadata on the way through, while WhatsApp's document path proved it left the file alone with a matching checksum. For a workplace tool the strip is arguably the better default, and for anyone relying on EXIF it is a silent data loss.