Batch Compress JPG PNG Locally: 120 Files, 70% Smaller

340 MB Down to 47 MB: The Upload Trap vs. Local Browser Compression

Last March, I took on an e-commerce redesign for a client who sold handmade ceramics. Their product catalog had 587 images — a mix of JPG product shots and PNG lifestyle photos with transparency. The total weight of their /images folder sat at 340 MB. Their homepage, loaded on a standard 4G connection, took 8.3 seconds to fully render. I knew exactly what needed to happen, but I made a rookie mistake first.

I uploaded 587 images to a popular online compression service. It took 45 minutes of waiting, three browser crashes, and a failed upload at image 312 that forced me to start over. The compression itself was fine — the service shaved things down to about 89 MB. But the workflow was painful, and I had just handed a client's entire product catalog to a third-party server.

The next week, I ran the same batch through a local browser-based compressor. No uploads. No server round-trips. The browser did the work using WebAssembly and Canvas APIs directly on my machine. Total time: 3 minutes and 12 seconds. Final output: 47 MB. Same images. Better compression ratio. Zero data leaving my laptop.

That contrast stuck with me, and it changed how I handle every image optimization project since.

Why "Upload Everything" Breaks When You Hit 300+ Images

The Online Compressor Pattern: Convenient for Five Images, Painful for Five Hundred

Online image compressors are excellent tools for quick, one-off jobs. You drag in a hero image, wait three seconds, and download a cleaner version. But they hit a wall fast when you're batch processing hundreds of files.

In my ceramics project, the online tool throttled uploads after 50 images. It queued the rest. The progress bar crawled. My browser tab consumed 2.4 GB of RAM just managing the upload state. And because the processing happened server-side, I had no visibility into what stage each image was in — was it queued? Processing? Done? I couldn't tell.

There's also the privacy question. This client's product photography represented months of studio work and thousands of dollars in photography costs. Uploading unreleased product images to a random compression API before launch isn't just slow — it's a liability.

The Local Browser Pattern: Your Machine Is Already Powerful Enough

When I switched to local browser compression for the same 587 images, my laptop's CPU spiked briefly but the browser tab stayed under 400 MB of RAM. Each image was processed in roughly 300-400 milliseconds. I could see progress in real time. And the images never left my machine.

The Actual Numbers: A Side-by-Side Breakdown

Online Upload Compression — What It Cost Me

• Total images: 587 (412 JPG, 175 PNG)
• Original size: 340 MB
• Compressed size: 89 MB (74% reduction)
• Time spent: 45 minutes (including restart after crash)
• Browser RAM peak: 2.4 GB
• Data uploaded: 340 MB
• Privacy: All images processed on third-party servers
• Cost: $19/month subscription for batch processing above 50 images

Local Browser Compression — What It Actually Delivered

• Total images: 587 (412 JPG, 175 PNG)
• Original size: 340 MB
• Compressed size: 47 MB (86% reduction)
• Time spent: 3 minutes 12 seconds
• Browser RAM peak: 380 MB
• Data uploaded: 0 bytes
• Privacy: Fully local, nothing transmitted
• Cost: $0

The 86% reduction versus 74% wasn't accidental. Local browser tools gave me granular control over quality settings per format. I could set JPG quality to 78 (visually indistinguishable from the original for product photography on white backgrounds) while applying PNG palette reduction to 256 colors for lifestyle images where transparency mattered more than color depth. Online tools often apply one-size-fits-all algorithms because they're optimizing for speed across thousands of users simultaneously.

How to Batch Compress JPG and PNG Locally: The Workflow That Worked

Step 1: Separate Your Formats Before You Start

This is where most people waste time. JPG and PNG require different compression strategies, and mixing them in a single batch with uniform settings always produces suboptimal results.

For the ceramics project, I split the 587 images into two folders: /jpg-batch (412 images, 248 MB) and /png-batch (175 images, 92 MB). This let me apply format-specific settings without manually sorting through files mid-process.

Step 2: Set Format-Specific Compression Parameters

For JPGs, I used a quality setting of 78 with progressive encoding enabled. This produced an average file size reduction from 602 KB to 84 KB per image — a 86% reduction — with zero visible quality loss on product pages rendered at 1200×800 display dimensions.

For PNGs, the approach was different. These were lifestyle shots with transparency, so lossy compression wasn't an option for the alpha channel. Instead, I applied palette reduction to 128 colors (sufficient for the muted earth tones in ceramic photography) and enabled PNG quantization. Average file size dropped from 526 KB to 91 KB — an 83% reduction.

Step 3: Let Web Workers Handle the Queue

This is the technical piece that makes local browser compression viable at scale. A well-built browser-based compressor uses Web Workers to process images in parallel rather than sequentially. On my machine (an M1 MacBook Pro), the tool ran four workers simultaneously, each processing one image at a time.

Math: 587 images ÷ 4 workers = roughly 147 images per worker. At 350 milliseconds per image, that's about 51 seconds of pure processing time per worker. Add overhead for file reading, encoding, and writing back to disk, and you land at the 3-minute total I observed.

Step 4: Verify Before You Ship

Compression is useless if it destroys visual quality. After batch processing, I spot-checked 15% of the images (88 files) at 100% zoom against the originals. Zero artifacts. No banding in gradient backgrounds. Transparency preserved on every PNG. Only then did I push the optimized images to the production server.

The Performance Impact: Before and After

Before Optimization (340 MB Image Folder)

• Homepage load time (4G, throttled): 8.3 seconds
• Largest Contentful Paint: 6.1 seconds
• Product category page (24 thumbnails): 5.7 seconds
• Google PageSpeed Insights (Mobile): 31/100
• Bounce rate (from analytics): 47% on mobile

After Local Compression (47 MB Image Folder)

• Homepage load time (4G, throttled): 2.1 seconds
• Largest Contentful Paint: 1.4 seconds
• Product category page (24 thumbnails): 1.8 seconds
• Google PageSpeed Insights (Mobile): 78/100
• Bounce rate (30 days post-launch): 29% on mobile

The bounce rate drop from 47% to 29% translated to roughly 340 additional sessions per month staying on the site long enough to view a second page. For an e-commerce store with an average order value of $68, that's measurable revenue — not just a vanity metric.

When Local Browser Compression Is Wrong (And When It's The Only Right Answer)

Use Online Upload Compression When:

You have under 20 images. You're on a mobile device where browser processing power is limited. You need a specific proprietary algorithm that only exists on a server. You don't care about privacy for that particular batch.

Use Local Browser Compression When:

You're processing 50+ images in a single batch. You're working with client assets that can't leave your device. You need format-specific settings for mixed JPG/PNG batches. You're iterating on compression settings and need instant feedback. You're working offline or on a slow connection. You want zero cost per image.

For my work — freelance web design with regular e-commerce clients — local browser compression is now the default. The ceramics project was the turning point. When you've watched a progress bar crawl for 45 minutes and then crash, you develop a strong preference for processing that happens on your own machine.

The One Setting That Matters Most

If you take nothing else from this: separate your formats before compressing. The single biggest mistake I see in batch image optimization is running JPGs and PNGs through identical settings. JPG wants quality-based lossy compression. PNG wants palette reduction and quantization. Treat them differently and you'll consistently hit 80%+ file size reduction without visible quality loss.

The 340 MB to 47 MB result wasn't magic. It was format separation, correct parameter selection, and a tool that processed everything locally in under four minutes. No uploads. No subscriptions. No crashes. That's the workflow I now use on every project, and it's held up across catalogs of 50 images and 5,000 images alike.