Dev.to WebDev 🛠 Dev 👁 0 📖 3 min read

What's actually inside a 40 MB .pptx?

Someone sends you a 40 MB deck. Twelve slides. Nothing on them looks like a high-resolution photo. So where did 40 MB come from? The answer is one unzip away, and it tells you a lot about how Office formats actually wor

Someone sends you a 40 MB deck. Twelve slides. Nothing on them looks like a
high-resolution photo. So where did 40 MB come from?

The answer is one unzip away, and it tells you a lot about how Office formats
actually work.

A .pptx is a ZIP full of XML

OOXML — .docx, .xlsx, .pptx — is a ZIP archive. Rename a copy to .zip
and open it:

[Content_Types].xml
_rels/.rels
ppt/
  presentation.xml
  slides/slide1.xml … slide12.xml
  slideLayouts/
  slideMasters/
  media/          <- here
  embeddings/
  fonts/

The XML describing twelve slides is measured in kilobytes. The whole deck's
structure — text, positions, colours, transitions — is tiny.

Practically all of the weight sits in ppt/media/. Sort that folder by size
and the culprit is usually obvious within seconds: a video someone dropped in
"just for reference", or one 8 MB JPEG that got reused as a background.

That has a very practical consequence: if you want to know why a file is big,
you don't need to guess. You look inside.

Cropping an image does not shrink the file

This is the one that surprises people.

Crop a 4000×3000 photo down to a neat circle on your slide. The slide now shows
a circle. The file still stores the full 4000×3000 image, because cropping is a
display operation — it changes which pixels are visible, not which pixels are
saved.

PowerPoint does give you a way to actually discard them: select the picture,
Picture Format → Compress Pictures, and tick Delete cropped areas of
pictures
. That checkbox, not the crop itself, is what removes the bytes.

Most "my deck is still huge" complaints are this.

Compress Pictures is lossy and permanent

The same dialog re-encodes the images at a lower resolution. Worth knowing before
you click it:

  • It is not undoable. Undo does not restore the original quality.
  • Keep an uncompressed copy if there's any chance you'll need it later.
  • 150 ppi is usually indistinguishable on a projector, and it's a big cut from the 220+ ppi that phones and stock photos ship with.

Video is a different story — and platform-dependent

File → Info → Compress Media re-encodes embedded video at Full HD 1080p,
HD 720p or Standard 480p. It's usually the single largest win on any deck with
video in it.

One catch: it exists in PowerPoint for Windows only. The Mac version has no
equivalent. On Mac you have to compress the video externally before inserting
it — which is a genuinely annoying asymmetry if your team is split across
platforms.

The quiet contributors

Two more things that add up:

Embedded fonts. Settings → Save → Embed fonts in the file. Fine if the
deck depends on a font your audience may not have; pure overhead otherwise.

Unused slide masters and layouts. Stock templates ship with a dozen layouts
across multiple masters. View → Slide Master, right-click, delete the ones no
slide uses. Each one carries its own background and theme assets.

And a smaller one: Save As under a new name. Incremental saves accumulate
editing history; a fresh save drops it.

Reading the file in the browser

The nice thing about all of this is that it's just a ZIP. Which means a browser
can read it too — File → ArrayBuffer, parse the central directory, list the
entries, sum the sizes. No server, no upload, no library.

That's what I ended up building: a page that takes a .pptx and shows you which
files inside it are responsible for the size
,
broken down by percentage. The file never leaves the device — it's read with the
File API and nothing is transmitted.

The whole trick is that there is no trick. The format is open, the container is
a ZIP, and the answer to "why is this file 40 MB" has been sitting in
ppt/media/ the entire time.

If you want the step-by-step version instead of the format explanation, that's
here: How to compress a PowerPoint file without ruining the images.

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.