How to Compress a Word Document on Mac

Decide first whether the recipient needs to edit the file. That question removes most of this table.

The second row is the one nobody writes about, and it is the most interesting, so it gets its own section.

Because Word stores every picture at the resolution it arrived at, not the size you dragged it to on the page. Shrinking a photo on screen changes a display instruction. The 4,032 × 3,024 original is still in the file.

Since Word 2007, a .docx has been a ZIP archive of XML parts plus a word/media/ folder. That means the Terminal command you already know works on it, and nothing needs installing:

unzip -l report.docx | sort -rn | head -8

On the test document that printed:

 25705174                     23 files
  4704261  09-26-2026 12:59   word/media/image2.jpg
  4502065  09-26-2026 12:59   word/media/image1.jpg
  4422839  09-26-2026 12:59   word/media/image3.jpg
  4000947  09-26-2026 12:59   word/media/image4.jpg
  3731400  09-26-2026 12:59   word/media/image5.jpg
  3509111  09-26-2026 12:59   word/media/image6.jpg
   438131  09-26-2026 12:59   word/stylesWithEffects.xml

And the total of the media folder, in one more line:

unzip -l report.docx | grep media | awk '{s+=$1} END {print s}'
24870623

Set that against the file on disk and the arithmetic is brutal. The document is 24,902,298 bytes. The six photographs are 24,864,304 of them once stored. Everything that is actually a document — all six pages of text, the headings, the styles, the theme, the font table, the numbering definitions — is 35,294 bytes. A third of one percent of the file. You could triple the writing and not notice.

One aside that trips people up when they run this: word/styles.xml and word/stylesWithEffects.xml look enormous in that listing, 349 KB and 438 KB. That column is the uncompressed length. Both are XML, both deflate to a few kilobytes, and neither is your problem. JPEGs do not deflate at all, which is why the media numbers are the same either way.

No. It made the test file slightly larger, and it costs you the ability to look inside.

The two formats are not variations on a theme. Run file on each and the difference is stated plainly:

$ file report.docx report.doc
report.docx:   Microsoft OOXML
report.doc:    Composite Document File V2 Document, Little Endian, Os: Windows…

A .docx is Office Open XML in a ZIP container, which is why unzip -l works on it. A .doc is a Compound File Binary structure, an OLE container Microsoft has been shipping since the early nineties. Point unzip at one and it tells you exactly what it thinks:

$ unzip -l report.doc
  End-of-central-directory signature not found.  Either this file is not…

The same content, saved both ways:

The binary format stores the same six JPEGs with more structural overhead and no container compression, so it came out 190,310 bytes bigger. If someone has asked you for a .doc, send one. Do not send one hoping it will save space.

It resamples the stored images down to a target resolution and optionally discards the parts of pictures you cropped away. Microsoft documents the Mac route as File → Compress Pictures, offering a Picture Quality list ordered highest resolution first, and a choice of Selected pictures only or All pictures in this file.

Two details from that page do the heavy lifting. Microsoft states that “the default picture resolution in Microsoft 365 is 220 ppi”, so a picture placed five inches wide keeps about 1,100 pixels across. And there is a Delete cropped areas of pictures checkbox, which is the single most under-used control in Office: cropping a photo in Word hides pixels, it does not throw them away, and a heavily cropped document can be mostly invisible image data.

We have not published a figure for it. Microsoft Office is not installed on the test machine, and a number we did not measure is worth less than no number.

Replace the pictures inside the archive with smaller versions of themselves. Because a .docx is a ZIP and Word sizes images by the display dimensions recorded in the XML, swapping a 4,032 px JPEG for a 1,600 px one changes nothing about the layout. The page looks identical. The file does not.

The six photos, compressed at 1,600 px on the long edge, quality 75:

Swapped back into the archive, report.docx went from 24,902,298 bytes to 831,852 bytes, 96.7% smaller. It still opened, still rendered six pages, and the images still filled the same five inches. At 1,600 px across five inches the pictures resolve 320 PPI, which is above what any printer will use.

This is a genuinely useful thing to know and also a slightly nerdy one: you are editing the inside of a document format by hand. If that appeals, the tooling is a ZIP utility and an image compressor. If it does not, Word’s own command and the PDF route both get you most of the way with no archaeology.

Worth stating plainly before anyone buys software for this: Smol does not compress a .docx in place. Handed the test file directly, it returns “This file couldn’t be processed. It may be corrupted or in an unsupported format.” What it does is compress the images that go in, and convert the document to pdf, docx, odt, rtf, txt or html.

If it is finished, yes. Converting the test document to PDF took 5,399 ms and produced a six-page file of 1,547,042 bytes, down 93.8%, because the conversion resamples each picture to the size it is actually printed at instead of the size it was shot at.

That is a bigger saving than Compress Pictures will typically give you, and it comes with the usual PDF trade: nobody can edit it, and nobody can accidentally reflow your layout on a different machine. If the PDF is still too large for whatever is rejecting it, that is a separate and well-trodden problem. See how to compress a PDF on Mac, or the routes that do not need Acrobat.

A deck has the same anatomy and one extra trap, because video survives the PDF export as an attachment: compressing a PowerPoint on Mac covers that.

Then the per-file routes stop being the answer and the folder becomes the unit of work. Converting fifty reports to PDF one File → Export at a time is an afternoon; dropping fifty on a converter is a minute.

The useful thing to fix, though, is upstream. A document built from 1,600 px images never becomes a 24 MB document, so the habit that pays most is a single compression pass over the photo folder before anything gets inserted. Same for the PDFs afterwards, which is the job batch compressing PDFs on a Mac exists for. If you are picking a tool for that, the field is ranked in the best PDF compressor for Mac.

If this is genuinely recurring, it is worth knowing that Smol ships an MCP server, so Claude Code, Codex and Google Antigravity can drive it directly. As of Smol 1.0.35 each is one click to enable in the AI access panel, and “compress every image in ~/Reports/photos to 1600px, then convert the documents in ~/Reports to PDF” becomes one instruction rather than a workflow you maintain. The full tool list is on the Smol MCP page. That is a genuinely narrow use case, and if your answer is “I do this twice a year”, ignore it.

If you have Word, File → Compress Pictures is free, it is right there, it understands cropped regions, and it keeps the file editable. Try it before anything else. For one document that is 30 MB because of four holiday photos, it is the whole solution.

If the document is finished, exporting to PDF from Word, Pages or LibreOffice is free and beat every other route in our test by a wide margin. Paying for that is silly.

And if you are comfortable in the Terminal, the ZIP-swap above needs no software at all beyond something to resize JPEGs, which sips does in one line.

Where Smol earns its keep is the repeating case: a folder of camera originals every week, a stack of documents to turn into PDFs, and those PDFs then squeezed under an upload cap. That is one drag instead of three apps. It is $29 once, it runs entirely on your Mac, and nothing about the document leaves the machine. For a single file, the free tools above are the right answer and we would rather you used them.