Before You Hit Upload in WordPress: Weigh, Compress and Re-Weigh Your Phone Photos (29 MB → 7 MB)

The first time I ran a small café site through PageSpeed Insights, the photos did most of the damage. The theme was fine and the plugins were fine. The problem was five pictures in one gallery block, dragged into the WordPress media library straight from the owner's phone. Together they weighed more than the rest of the site combined.

Since then I go through the same short checklist before any phone photo gets near the Upload button: weigh the page, compress the batch in the browser, check the files, zoom in on one, then weigh the page again. Below is that checklist with a real run, five full-size phone photos that went from 29.1 MB to 7.1 MB. I also cover two things WordPress does with big images that most people don't expect. The compressor I use is PixSip, which I make, so keep that in mind as you read.

The five photos I tested with

To keep this honest I didn't use web-ready sample images. These are five unedited phone photos from Wikimedia Commons, all released as CC0 (public domain): a café storefront and a pastry counter shot on a Samsung (4032×3024), a Tokyo bakery front (4080×3072), a café breakfast table shot on a OnePlus (4608×3456), and a cake counter from a Google Pixel 8 Pro in its 50 MP mode (8160×6144, 8.7 MB). Every one of them still had its EXIF data, including GPS coordinates. That's exactly what a phone hands you, and exactly what tends to end up on small business sites.

Step 1: Weigh the page before you change anything

You can't tell whether you've fixed anything without a "before" number. On a live site, open Chrome DevTools (F12), go to the Network tab, filter by Img, tick Disable cache and reload. The total at the bottom tells you how many megabytes of images the page pulls. PageSpeed Insights flags the same problem under "Improve image delivery".

For this post I built a bare test page with one gallery block holding the five originals, served it locally, and loaded it in Chrome on an emulated 10 Mbps connection (about what a busy café Wi-Fi or a so-so mobile signal gives you):

That's 29.1 MB of images and a 23.4-second wait for the page to finish loading, and the biggest single file is 8.7 MB. Write your own numbers down. You'll need them in Step 6.

Step 2: Open the JPG compressor and wait for the lock

Go to PixSip's Compress JPG page. There's no account to create and nothing to install. The free plan takes up to 20 photos per batch at up to 10 MB each, so even the 8.7 MB Pixel shot fits.

One small thing: give the page a second or two after it opens. It loads its encoder (MozJPEG compiled to WebAssembly) in the background, and the drop area stays disabled until that's done. When the small spinner under "Drop images here" turns into a 🔒, it's ready. For me that took about 1.2 seconds.

Leave the "Convert my images automatically" switch on and keep JPG as the selected format. That's all the setup there is. PixSip has no quality slider and no "target size" box. It re-encodes every photo at one quality that the team calibrated against TinyPNG, so there's nothing to tune and nothing to get wrong.

Step 3: Drop the whole folder at once

Select all the photos for the page and drag them onto the drop area together. One batch beats five separate runs. Each photo is compressed inside your browser tab: I watched the network log during the run and no image data left the machine. The only outgoing requests were three tiny analytics pings of 1.3 to 2.2 KB each, far too small to carry a photo. (If you want the longer version of how that works, PixSip has a post on why it keeps files on your device by default.)

All five were done in about 11 seconds in headless Chrome on my machine:

Photo	Pixels	Original	After PixSip	Saved
cafe-storefront.jpg	4032×3024	5.4 MB	1.5 MB	−73%
bakery-counter.jpg	4032×3024	4.4 MB	994.9 KB	−77%
tokyo-bakery.jpg	4080×3072	6.4 MB	1.4 MB	−78%
croissant-breakfast.jpg	4608×3456	4.2 MB	682.6 KB	−84%
cake-counter-50mp.jpg	8160×6144	8.7 MB	2.6 MB	−70%
Total		29.1 MB	7.1 MB	−75%

The summary line read "Saved 21.9 MB total · 75% smaller". That's a lot more than PixSip's own 20-image benchmark against TinyPNG shows, and there's a simple reason: photos straight off a phone are saved at a very high quality, so there's much more to trim than in images that have already been through an editor or a CMS.

Step 4: Download the ZIP and check what's actually in it

Click Download 5 as ZIP (the number follows your batch size). The archive is built in the browser too, and every file comes back with -compressed added to its name. Before I upload anything, I compare the new files with the originals. Here's a short Python check that reads the pixel size and EXIF data of every file:

Three things to notice:

• The pixel sizes are unchanged. PixSip compresses; it doesn't resize or crop. The 50 MP shot is still 8160×6144.
• The GPS coordinates are gone, along with the rest of the EXIF block (camera model, timestamps). For photos going on a public website, that's usually what you want. If you need to keep a copyright line in the metadata, add it back afterwards.
• Your originals aren't touched. They stay on your disk as the masters, so keep them.

Step 5: Spot-check one photo at 100%

A percentage on its own says nothing about how the photo looks. Back on the results list, click Compare on the photo with the most fine detail. I picked the pastry counter: crumbs, flaked almonds and hand-written chalk labels. Drag the divider across, then press Zoom 1:1 so that one screen pixel shows one image pixel, which is where compression damage would show first:

To double-check outside the tool, I cut the same 600×450 pixel patch out of the original and the compressed file at 100%, with no scaling, and put them side by side:

The chalk lettering is the part I'd expect to break first, and I can't find a difference between the 4.4 MB file and the 994.9 KB one. If a photo of yours does look worse here, keep the original for that one and compress the rest.

Step 6: Weigh the page again

Same test page, same emulated 10 Mbps connection, compressed files swapped in:

Image weight went from 29.1 MB to 7.1 MB, the largest file from 8.7 MB to 2.6 MB, and the load event from 23.4 s to 5.8 s. Nothing else on the page changed. If your own before-and-after numbers don't move like that, the heavy images are probably coming from somewhere else, such as a slider plugin or a background image set in the theme.

WordPress notes: what happens after you click Upload

A few things I wish I'd known earlier about how WordPress treats big photos:

• Photos wider or taller than 2560 px get a "-scaled" copy. Since WordPress 5.3, any upload over that threshold (the big_image_size_threshold filter) is scaled down to fit 2560 px, and the copy is saved as name-scaled.jpg. That copy becomes the "full size" image your theme uses. WordPress encodes it itself (at its default JPEG quality of 82), so for photos that big the compressed upload mostly pays off in storage, backups and upload time. The part that actually reaches visitors is the scaled copy.
• Your original is still on the server. WordPress keeps the file you uploaded in /wp-content/uploads/ next to the scaled copy, at a URL anyone can open if they guess it. Upload an untouched phone photo and that public original still has its GPS coordinates. Upload the PixSip file and it doesn't, and it's 75% lighter on your hosting quota.
• Thumbnails don't shrink the original. The 150, 300, 768, 1024, 1536 and 2048 px sizes WordPress generates are extra files. They help where your theme uses them, but a block set to "Full size", a lightbox or a page builder linking to the full image still pulls the full-size file.
• Under 2560 px, what you upload is what visitors get. If you export or crop your photos to 2560 px or less before compressing, the PixSip file is the full-size image, and every kilobyte you saved in Step 3 comes off the page. Doing both, smaller dimensions and then compression, gets you the biggest win.
• Rename before you upload. The file name becomes part of the image URL, so change cake-counter-50mp-compressed.jpg to something like lemon-cake-counter.jpg first, and fill in the alt text in the media library.

If you're doing a whole site at once and need more than 20 photos per batch, that's what the paid plans are for. For a single page or product gallery, the free batch has always been enough for me. And if the same page also has a phone video on it, that's a separate problem with its own fix: I use vidsmaller.com to shrink the clip to a set size before it goes in.

The checklist, short version

1. Weigh the page first (DevTools → Network → Img, or PageSpeed Insights).
2. Open the browser-side JPG compressor and wait for the 🔒.
3. Drop the whole batch; read the per-file and total savings.
4. Download the ZIP and confirm the pixel size is unchanged and the GPS is gone.
5. Zoom one detailed photo to 1:1 before you trust the rest.
6. Weigh the page again, then upload, renaming the files as you go.

Photos: "Jacob's Bakery + Cafe 2024-04-15", "Bakery products on the counter of Jacob's Bakery + Cafe 2024-04-15" and "Food for sale at the counter of Mokoko Coffee & Bakery 2025-07-25" by Andy Li; "Bakery in Tokyo" by Syced; "Coffee, breakfast, croissant" by Kurt Kaiser. All CC0 via Wikimedia Commons.

Related: my Medium walkthrough of the same routine with a different photo set · WebP vs AVIF: which one is actually smaller for your photos (DEV.to) · converting iPhone HEIC photos to JPG with the Wi-Fi off