Does Google Slides Compress Images? Yes. I Measured It

Yes, and mine lost three quarters of its bytes. Does Google Slides compress images? On 2026-07-18 I inserted a 4.13 MB iPhone photo into a deck and got back a 937.8 KB JPEG, resized from 4032x3024 to 2048x1536. A smaller 1.78 MB PNG came back byte identical. Compression is real, and it is conditional.

Scope, stated plainly: that is one deck, one day, one path in and back out, two reference files. The mobile app, another insert path, or next month's build of Slides can behave differently. What a dated measurement buys is a real number on a question that has run on forum anecdotes since 2016, because no page on this search result ever ran the test.

Does Google Slides Compress Images? What I Measured

Slides re-encoded and resized my photo, and it stored my PNG byte for byte. Both results came from the same insert path on the same day, and together they draw the line this page is about: the behavior is conditional, keyed to the image you hand it.

The two reference files

Same two files as every app in this series, so the pages compare cleanly. REF-A is a real iPhone photo, 4,332,705 bytes, 4032x3024, a JPEG with its EXIF block in place. REF-B is a photographic cutout with genuine transparency, 1,863,465 bytes, 1240x930, an RGBA PNG. Every result in the series sits side by side on the measured hub covering which apps compress your images.

One file crushed, one untouched

The photo came back a different file: 937.8 KB against the original 4.13 MB, and 2048x1536 against the original 4032x3024. That is 77.8% of the bytes gone and, doing the pixel arithmetic, 74% of the pixels: 12.2 megapixels went in, 3.1 came out. The PNG came back with the same sha256 hash it went in with, the strictest pass a file can get: no re-encode, no resample, not one byte moved. Two files, two opposite outcomes, one policy, and the rest of this page is about where the line between them sits.

Where Is the Resize Ceiling? 1600, 2000, or 2048 Pixels

My photo's long side came back at exactly 2048 pixels, and that lands on one side of a decade old argument. Ask does Google Slides compress images anywhere public and the answer arrives with one of two numbers attached, 1600 or 2048, both of them folklore that nobody had re-measured.

The folklore: 1600, 2000, and an AI Overview repeating both

Google has never published the threshold. The 1600 figure comes from the canonical 2019 complaint thread on Google's own support forum, an early Stack Exchange answer put it near 2000, and the AI Overview sitting on top of this search result currently tells people 1600 to 2000 pixels, citing those same forums back at themselves. The most careful community source, an investigation on r/GoogleSlides, concluded that large images are resized to fit within a 2048x2048 box. My 2026 measurement lands on their side of the line: 4032x3024 in, 2048x1536 out, the long edge parked precisely on 2048.

What one dated test pins down

Here is what one test can and cannot pin down. Mine brackets the trigger: a 1240 pixel wide PNG passed untouched, a 4032 pixel wide photo got resampled, and I did not test the widths between, so the exact tripwire sits somewhere in that gap. What the output does pin down is the ceiling: what survives comes out no larger than 2048 on the long side, at least on the path I measured on 2026-07-18. The 1600 figure did not match my result on either end.

Google's published caps are a different rule

The only numbers Google publishes are hard caps, not resample rules: an inserted image must be under 50 MB and under 25 megapixels, per the Google Slides API documentation on adding images, which also lists the officially supported formats as PNG, JPEG, and GIF. Those caps reject a file outright at the door. The resample ceiling is a different animal, undocumented and silent, visible only if you measure what Slides stored.

The 2016 observation my files confirmed

The oldest useful observation on this topic still holds up. A 2016 Stack Exchange thread noticed that most inserted images came through unmodified while some came back degraded, which is exactly the conditional behavior my two files reproduced a decade later. And the 2048x1536 output is a familiar shape: Facebook returned the same photo at the same 2048x1536 in this same test series. Two unrelated pipelines converging on one box tells you 2048 is a standard web display budget, not a Slides quirk.

Why Does Google Slides Compress Photos?

Because Slides is a renderer that has to load fast on whatever screen opens it, not a locker that has to preserve what you gave it. A deck lives on Google's servers and streams to every viewer, including the phone on hotel wifi. A 12 megapixel camera original displayed inside a 1920x1080 canvas spends nearly all of its pixels on nothing any viewer can see, so Slides resamples oversized rasters down to a size that serves the canvas.

The resample is silent. There is no dialog, no notice, no changed filename, and the first anyone learns of it is a logo gone soft on the projector. Most running complaints about Google Slides image quality trace back to exactly this event, discovered after the fact.

The contrast with a document app makes the mechanism obvious. In this same test series, a Word document handed both reference files back byte identical, because a document is a container and containers carry cargo. A slide canvas re-renders its contents, and for a JPEG that re-encode is lossy generation loss, detail that never comes back. Fast decks over faithful pixels is a defensible trade. It is just never announced to the person who loses the pixels.

How the Photo Gets In Changes What You Get

Insert from a file is the clean path, and paste is the one that costs you before Slides even runs. The community record here is unusually consistent: a picture pasted from the clipboard arrives as a screen resolution bitmap, already degraded before any Slides processing happens, while Insert, then Image, then Upload from computer delivers the original file. Reports that inserting from Google Drive preserves more than a computer upload exist, but they are anecdotes with no controlled test behind them, mine included. My measured numbers cover the file insert path only.

Byte weight is the other half of the entry decision. Phone photos run four to six megabytes each, and a deck carrying twenty of them drags on every open. Compress the photos before they go in: at quality 80 a typical camera original comes back 60 to 80% smaller with nothing visible lost at normal viewing. Compression trims bytes, not pixels, so pair it with a resize when the image is over the ceiling; the payoff is a deck that opens fast and, for files already inside the limits, pixels that Slides stores untouched, the way it stored my PNG.

The Built In Controls: Compress Images and Reduce File Size

Slides ships two opt-in compressors, and neither one is the automatic resample. The tutorials that document them describe a per image control at Format, then Image options, then Compress images, with High, Medium, and Low levels, and a whole deck control at File, then Reduce file size that resamples every embedded image toward screen resolution. Google publishes no quality percentages for any of those labels, and I have not measured them yet, so treat them as directions of travel rather than promises.

What matters for this page's question is that they only run when you invoke them. They are cleanup for a deck that is already bloated, and they cannot restore anything the automatic resample already spent. Control that actually holds comes from preparing the file before it goes in, which the workaround section below covers step by step. And if the goal is a smaller deck overall rather than sharper images, the two levers beyond images are video, embedded from Drive or YouTube instead of uploaded into the file, and unused slides left sitting in the deck.

What Happens on Export to PDF, PPTX, or PNG?

Export is a second, separate compression event, and surviving the insert does not mean surviving the download.

PDF export: documented recompression

PDF is the harshest documented path. A Google product expert states that exporting compresses images and pegs the PDF export canvas at a 1600 pixel maximum, per this Google Docs Editors thread on PDF export quality. The standard mitigation is enlarging the deck before exporting through File, then Page setup, which accepts custom dimensions, per Google's documentation on changing slide size. I did not measure the export paths; my numbers stop at what Slides stores.

PPTX: the audit and recovery path

PPTX is the audit path. Download the deck as PowerPoint, rename the file's extension to .zip, and the ppt/media/ folder inside holds every image exactly as Slides stored it, downsample included if one already ran. That makes it two things at once: the recovery route for the best surviving copy of your images, and the two minute check for what Slides actually did to them.

Per slide image export: 960x540 by default

Per slide image export is the quiet disappointment. The tutorials that cover it put the default PNG or JPEG output for a widescreen deck at 960x540 pixels, half the canvas in each direction, and the same Page setup adjustment is the only lever that raises it.

Which Format Should You Upload to Google Slides?

JPEG for photographs, PNG for anything with text, hard edges, or transparency, and convert everything else before Slides sees it.

The officially supported upload list is PNG, JPEG, and GIF, per the same Slides API documentation that sets the size caps. WebP, the format most of the modern web serves, is not accepted through the standard insert menu, so convert the WebP to JPG and insert the result. SVG files lose their vector nature on the way in, which means logos are better delivered as PNGs pre-sized to their display dimensions.

Between the two workhorses, pick by content rather than habit. A photograph saved as PNG runs three to five times the bytes of an equivalent JPEG with nothing visible gained on a slide, and the resample ceiling keys on pixels either way. A screenshot or diagram saved as JPEG grows halos around every hard edge. Transparency needs PNG, no exceptions.

Does Google Slides Strip EXIF Data?

Not from files it stores untouched. My byte identical PNG is direct proof: every byte in, every byte out, embedded metadata included.

The re-encoded photo is the honest unknown. My measured store recorded its bytes and dimensions but not a metadata read on the stored copy, and a re-encode may rewrite or drop EXIF, the hidden block where your camera writes GPS coordinates, device model, and timestamp. I will not claim either outcome without that reading, and no source I found has published one for Slides. For contrast, Google Drive is documented as storing files without touching EXIF at all, which fits the container versus canvas split this page keeps running into.

The practical call does not need the missing measurement. If a deck is going public and its photos came off your phone, strip the metadata before insert; the compressor I run does it by default, on every file, because location data has no business inside a shared presentation.

How Google Slides Compares to Google's Other Apps

Slides is the only Google product in my test series that touched the photo. Same 4.13 MB file, same day, four different answers.

Google Drive stored the photo byte identical, because Drive is storage, and storage that edits your files would be broken. Google Photos splits by your account setting: original quality kept every byte, while storage saver recompressed the file 35.1% smaller and kept all 4032x3024 pixels. Slides alone re-encoded the photo and threw pixels away. That is not an inconsistency, it is three products doing three jobs, and the mistake is treating a slide deck like the family album. A deck is a display surface, and display surfaces spend your pixels to buy speed.

How to Stop Google Slides From Compressing Images

You cannot turn it off. There is no setting, no high quality toggle, no plan tier that changes it, so the only control you have is the file you hand it. Five habits, in working order:

1. Size the pixels to the job before inserting. A full slide on the standard widescreen canvas is 1920x1080, and a content image rarely needs more than the region it occupies. Under the measured 2048 ceiling, my test says Slides stores what you gave it. The methods are in how to reduce image resolution.
2. Compress the bytes next, at quality 80. Pixels set the sharpness; bytes set how fast the deck opens and how far you sit under the 50 MB per image cap.
3. Insert the file. Never paste it, because the clipboard path degrades the image before Slides is even involved.
4. For graphics that must stay sharp past the ceiling, use the community slicing trick: cut the image into tiles, each under the ceiling, and place them edge to edge. Tedious, and it works.
5. Keep the master copy outside Slides. A deck is not an archive, and the PPTX recovery trick returns only what Slides kept, never what the resample spent.

Resize first, compress second, insert third. Run that order once and Google Slides has nothing left to decide for you.

Hand Slides a File It Has No Reason to Touch

My PNG went through Google Slides untouched because it arrived already sized for the job. That is the entire strategy. Google Slides compresses images that give it a reason to and stores the ones that do not, so make yours the second kind.

Run the deck's photos through the compressor before they go in: quality 80 returns a typical camera original 60 to 80% smaller with nothing visible lost, up to 25 MB per image, 30 at a time, free, no signup. It also strips EXIF by default, so a shared deck is not carrying GPS coordinates in its media folder. Resize to display size, compress the bytes, insert the file, and every pixel your audience sees is one you chose.