Not in my test, and that result needs explaining. Does Microsoft Word compress images? Microsoft's own documentation says yes, to 220 ppi by default, every time you save. Yet on 2026-07-18 I put a 4.13 MB iPhone photo and a 1.78 MB transparent PNG through a Word document, and both came back with the same sha256 hash as the originals. Documented compression, untouched bytes. This page covers both halves.
| My test, 2026-07-18 | Went in | Came out | Change |
|---|---|---|---|
| iPhone photo (JPEG) | 4.13 MB, 4032x3024 | 4.13 MB, 4032x3024 | 0%, byte identical |
| Transparent PNG | 1.78 MB, 1240x930 | 1.78 MB, 1240x930 | 0%, byte identical |
| EXIF metadata | present | present | untouched |
Scope first: that is two reference files, one day, one machine, one copy of Word, one path into a document and back out. It does not prove what every Word build does with every setting, and Microsoft's documentation describes behavior my files never triggered. The measured half and the documented half are both below, kept clearly apart.
Does Microsoft Word Compress Images? What I Measured
In my test, nothing changed. Both reference files survived the round trip through a Word document with every byte intact, the same sha256 hash in and out, which is the strictest pass a file can get.
The two reference files
Every app in this series meets the same two files, so the results line up across pages. REF-A is a real iPhone photo: 4,332,705 bytes, 4032x3024, JPEG, with its EXIF block intact. REF-B is a photographic cutout with real transparency: 1,863,465 bytes, 1240x930, PNG with an RGBA alpha channel. One consistent pair of inputs is the only way to put Word next to Google Slides or Outlook and have the comparison mean anything.
What byte identical means
A matching file size proves little, because two JPEGs can read the same in a file browser and still differ by a re-encode that cost you detail. A matching sha256 hash is a different class of evidence. Every byte is in the same place, so there was no re-encode, no downsample, no metadata rewrite, and no format change. Word held my files the way an archive holds them, which is nearly literal, since a .docx is a zip package with the images stored inside it.
What this result does not prove
It does not prove your document behaves the same way. Word's handling depends on the build, the document's image settings, and how the picture got in, and Microsoft's own pages describe a compression pass my files never met. Every result in this series carries the same honesty about its limits, and the hub on which apps compress your images keeps all of them side by side.
What Word Is Documented to Do: 220 PPI on Save
On paper the answer is yes. Microsoft's troubleshooting documentation states that Word, PowerPoint, and Excel perform a basic compression of images on save, per Microsoft's guidance on image quality loss in Office documents, and the default resolution for pictures in a new Word document is 220 ppi, pixels per inch, the measure of how much pixel data survives relative to printed size. The full set of targets is documented on Microsoft's page on reducing picture file size.
| Setting | Resolution | Intended for |
|---|---|---|
| 96 ppi | smallest files for sharing | |
| Web | 150 ppi | screens and digital documents |
| 220 ppi | the default for new documents | |
| HD | 330 ppi | high resolution displays |
| High fidelity | no downsampling | original quality |
The timing matters. Compression fires at save, not at insert, so a picture sits at full quality in the editor until the document is written to disk. With AutoSave running against OneDrive, that write happens within seconds of insertion, which means the window to change settings after inserting is effectively gone. And for a JPEG the cost compounds: re-encoding an already lossy file is generation loss, the stacking damage explained in lossy versus lossless compression.
The 220 ppi default is per document
The setting lives in each file, not in the application. Every new document starts back at 220 ppi unless you change the scope dropdown to All New Documents when you set it, and that per document trap is the most common reason people believe they fixed this and then meet it again next week.
High fidelity, the closest thing to off
The High fidelity option skips downsampling entirely and arrived in Office 2016, per Microsoft's page on changing the default picture resolution. The same page notes a telling detail: PowerPoint already defaults to High fidelity. Word does not, so the two apps treat the same inserted photo differently out of the box.
Compress Pictures, the manual squeeze
Word also compresses on demand. Select a picture, open the Picture Format tab, and Compress Pictures in the Adjust group lets you apply any preset to one image or all of them, and can delete cropped areas of pictures for good. A separate option under Image Size and Quality, discard editing data, throws away the stored undo history that quietly inflates files. The presets are blunt but effective, and one user on Microsoft's Q&A forum reported the Web preset taking a picture heavy document from roughly 100 MB to about 10 MB. Two things it will not do: dragging a picture smaller on the page never reduces its stored bytes, and cropping alone keeps every hidden pixel in the file. The full in-app walkthrough lives in compressing images in Word.
Why Did My Photos Come Back Untouched?
Because Word's automatic compression is conditional, not constant, and on my path the conditions never fired. The official line and the observed behavior disagree more often than either side admits, and this question sits exactly on the fault line.
Read literally, the documentation predicts my JPEG should have come back changed. A basic compression pass on save, a 220 ppi ceiling, a 12 megapixel photo: that math ends in a smaller file. It did not happen. Both hashes matched.
The other side of the argument has a face. Paul Edstein, a longtime Microsoft MVP who answered Word graphics questions for years, has maintained that Word stores images at full resolution unless compression is actively invoked. My result lands on his side of the line, for one build, one document, one day. I am not claiming one test settles a decade of conflicting reports.
What the reports do settle is that the confident version of either answer is wrong. A June 2025 report on Microsoft's own forum describes the exact opposite failure: a user set do not compress images in file plus High fidelity in a template for 600 dpi scans, and Word silently reverted the setting to 220 ppi and recompressed anyway, per this Microsoft Q&A thread on the setting being ignored. So does Microsoft Word compress images? Sometimes when it promises not to, and sometimes not when its documentation says it will. Treat the default as untrustworthy in both directions: set the options explicitly, then verify.
How to check what Word actually did
The .docx container makes verification a two minute job, no tools required:
- Copy the document, so the original stays safe.
- Rename the copy's extension from .docx to .zip.
- Open the archive and go to the
word/mediafolder. - Compare the stored images against your originals: byte size and pixel dimensions tell you immediately whether a compression pass ran.
That comparison is exactly how a byte identical claim gets proven, and it works on any Word document from the last two decades.
Does Word Compress Photos More When You Paste Them?
Paste is the path that actually costs you. How a photo enters the document changes what Word stores more than any compression setting does, and it is the difference most people never look at.
Insert, then Picture, from a file on disk embeds the original file with its format kept: a JPEG stays a JPEG, a PNG stays a PNG. Dragging a file in from a folder behaves the same way in modern Word. Pasting is different. A picture copied from a browser or another app arrives as a clipboard bitmap, re-encoded before Word ever touches it, larger and often worse looking than the file it came from.
The published numbers are stark. A technical documentation team measured the same images at 2,027 KB pasted against 300 KB inserted, and an independent Word tips site measured a two photo document at 435 KB pasted against 146 KB inserted. Same pictures, triple the weight, for one habit.
| How the photo goes in | What Word stores | Size effect |
|---|---|---|
| Insert, then Picture | the original file, format kept | baseline |
| Drag from a folder | same as Insert in modern Word | baseline |
| Paste from a browser or app | a re-encoded clipboard bitmap | several times larger |
Phone photos are the worst case, at four to six megabytes each straight off the camera. If the document has to travel by email, decide the size yourself: compress the photo before it goes in, then Insert, then Picture the smaller file. A photo that enters at 800 KB leaves nothing for Word's pipeline to shave and nothing for the paste path to triple.
How to Stop Word From Compressing Images
Two settings, set before you insert anything: Default resolution to High fidelity, and the do not compress images in file box checked. Everything else in this section is about making those two survive contact with real Word behavior, which is the part the official pages skip. The exact steps for every Office app are on Microsoft's turn off picture compression page.
On Windows, step by step
- Open File, then Options, then Advanced.
- Scroll to Image Size and Quality.
- Check do not compress images in file.
- Set Default resolution to High fidelity.
- Do this in a blank document before any pictures go in, because compression that already fired on a previous save is permanent.
On a Mac
Open the Word menu, then Preferences, then Edit, and find the Image Size and Quality options there. Mac users have repeatedly reported the checkbox reverting after a save and reopen, and in those reports setting Default resolution to High fidelity held more reliably than the checkbox alone. Set both, then spot check with the zip trick above.
Make it stick for every document
Both controls default to the current document only. Change the scope dropdown to All New Documents when you set them, or every fresh file quietly starts back at 220 ppi. This one dropdown is the difference between fixing the problem and fixing one file.
The registry switch
For Windows machines you administer, the same Microsoft troubleshooting page documents a registry value that disables basic compression application wide: a DWORD named AutomaticPictureCompressionDefault set to 0 under HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\Options, where 16.0 covers Office 2016 and everything after it.
When the setting does not hold
The June 2025 report above is not unique, and the pattern in the complaints is consistent: settings stored in templates revert, and newly inserted images get recompressed against the user's explicit instruction. Two habits protect you. Keep the original photos outside the document, treating Word as a layout, never as the archive. And verify the stored bytes with the zip check after the first save, because that is the only moment the truth is cheap to learn.
Does Word Strip EXIF Data From Photos?
Not when it leaves the file alone, and my test is direct evidence: a byte identical file still carries every byte of its EXIF block, the hidden metadata your camera writes into each photo, including GPS coordinates, camera model, and the exact timestamp. My iPhone photo's metadata rode through Word untouched.
The caveat runs through Edstein's expert answers on the same forums: when Word's compression does fire, the re-encode deletes the EXIF data with it, and there is no first party Microsoft documentation of exactly which fields go. So the metadata question inherits the compression question's answer, conditional both ways.
That cuts in two directions. For an archive, surviving EXIF is correct behavior. For a document you are about to send a stranger, it means the location where a photo was taken can ride along inside the .docx. The compressor I run strips EXIF by default for exactly that reason, before the file goes anywhere.
How Word Compares to the Other Apps I Tested
Word sits at the gentle end of the series, next to Google Drive and the attachment paths, and the interesting neighbors are Microsoft's own products. Same 4.13 MB photo, same test series, measured on disk.
| App and path | Photo came back | Change | Dimensions |
|---|---|---|---|
| Facebook post | 579.7 KB | 86.3% smaller | resized to 2048x1536 |
| Outlook, inline in the message | 819.1 KB | 80.6% smaller | resized to 1920x1440 |
| Google Slides, inserted in a deck | 937.8 KB | 77.8% smaller | resized to 2048x1536 |
| Gmail, inline in the message | 1.86 MB | 55.1% smaller | kept 4032x3024 |
| Canva, JPG export | 2.34 MB | 43.5% smaller | kept 4032x3024 |
| Microsoft Teams | 3.90 MB | 5.7% smaller | kept 4032x3024 |
| Word document | 4.13 MB | 0%, byte identical | kept 4032x3024 |
The pattern is not Microsoft versus everyone else, because Microsoft's own products land at three different points on that chart. A document is a container, so Word and the attachment paths keep your bytes: Outlook does the same split, byte identical as an attachment and 80.6% smaller pasted inline, and Gmail behaves the same way. A canvas is a renderer, so Google Slides re-encoded it down 77.8% on insertion. The moment your photo becomes part of a display surface instead of cargo, it gets recompressed.