You know that moment when you export a gallery and your laptop fan sounds like it’s about to take off?
Or when you push a website update and realize your “quick” hero image is 4.8 MB… and now your page feels like it’s loading on a 2009 Wi‑Fi router?
Batch compression is the unglamorous fix for both problems. And honestly, once you dial in a sane workflow, it stops being “one more thing” and becomes that quiet habit that saves you hours (and a lot of client-side embarrassment).
This guide is for two kinds of people:
- Photographers who want smaller deliverables without destroying the look of their images.
- Web developers who want faster pages, better Core Web Vitals, and fewer “why is this so slow?” messages.
What “batch image compression” actually means (in real life)
Batch compression isn’t just “make files smaller.” It’s usually a bundle of four decisions:
- Resize (dimensions): Don’t ship 6000px images if they’ll be displayed at 1400px.
- Convert (format): JPG vs PNG vs WebP (and when each one makes sense).
- Compress (quality/efficiency): Reduce bytes while keeping the photo looking… like a photo.
- Clean (metadata): Remove EXIF/GPS if privacy matters (and it often does).
If you only do one of these steps, you’ll still see improvement. If you do them in the right order, you get that “wait, it’s that small now?” result.
The golden rule: never compress your only copy
Between you and me, the biggest compression mistake isn’t using the “wrong” slider.
It’s compressing the only version of a file.
Keep a master (RAW, TIFF, PSD, or your high-quality export), then create delivery copies:
- Web-sized gallery versions
- Social media versions
- Website versions (WebP, responsive widths)
- “Email-friendly” versions
You’ll thank yourself later when a client asks for a print, or when your site redesign suddenly needs larger images again.
Two goals, two mindsets: photographers vs web devs
If you’re a photographer: your deliverables are a product
Your images are being judged. Skin tones, gradients, fine detail—people notice when compression gets crunchy.
Your batch compression goal is usually:
- Keep the look consistent
- Avoid visible artifacts (especially in skies, hair, and bokeh)
- Deliver files that download quickly and don’t clog phones
If you’re a web dev: bytes are UX
On the web, image weight often dominates pages. Trimming even a few hundred KB from key images can improve load time and perceived speed. Web.dev’s image guidance is blunt for a reason: images are frequently the easiest big win. (web.dev)
Your batch compression goal is usually:
- Reduce transfer size
- Use modern formats (often WebP) for broad support
- Serve the right dimensions for each breakpoint
The workflow that works (and doesn’t make you hate your life)
Here’s the order I recommend, because it matches how images bloat in the real world.
Step 1: Resize first (this is where the big savings hide)
If an image is displayed at 1200px wide, exporting it at 4000px is like shipping a fridge when someone asked for a lunchbox.
Use Resize Image before you compress. You’ll typically get the biggest size drop here with zero “quality debate.”
Practical starting points
- Website hero images: 1600–2400px wide (depends on layout)
- Blog content images: 1200–1600px wide
- Product grid thumbnails: 600–1000px wide
- Email: 800–1200px wide (email clients don’t need 4K)
Step 2: Convert to the format you actually need
A lot of “compression problems” are really “format mismatch” problems.
- Photos → usually JPG or WebP
- UI screenshots with text → often PNG (or lossless WebP)
- Transparent assets → PNG (or WebP with transparency)
For web delivery, WebP is a strong default. Support is excellent in modern browsers. (caniuse.com)
Tools that fit naturally into batch work:
- Convert mixed sources to WebP: Image to WebP
- If you’re starting from JPGs: JPG to WebP
- If you’re starting from PNGs: PNG to WebP
- If someone gave you a giant PNG photo with no transparency (it happens): PNG to JPG
- If your camera roll is full of iPhone photos: HEIC to JPG or HEIC to WebP
Step 3: Compress (with your eyes, not your ego)
Compression isn’t a contest. The goal isn’t the smallest file—it’s the smallest file that still looks clean.
Use Compress Image, then spot-check at 100% zoom:
- Look at skin, hair, sky gradients, shadows
- Watch for banding and “mosquito noise” around edges
- If you see artifacts, back off a bit
Honestly, the “perfect” setting changes based on the photo. A high-detail street shot needs different handling than a smooth studio backdrop.
Step 4: Strip metadata when privacy matters (spoiler: it often does)
Photos can carry EXIF data like:
- GPS location
- Camera model and lens
- Date/time
- Sometimes even edit history, depending on the pipeline
If images are going to clients, public galleries, listings, or social posts, consider cleaning them.
Use Remove Image Metadata to strip sensitive EXIF without changing the visible pixels.
A practical “batch settings” cheat sheet
These aren’t laws of physics—just sane defaults that work surprisingly well.
| Use case | Recommended format | Typical max width | Notes |
|---|---|---|---|
| Wedding/event gallery for web viewing | WebP (or JPG) | 2000–3000px | Keep detail, avoid aggressive compression in faces/skin |
| Portfolio homepage hero | WebP | 1600–2400px | Prioritize size; test LCP image first |
| Blog images inside articles | WebP (or JPG) | 1200–1600px | Most users won’t benefit from 4K here |
| UI screenshots with text | PNG (or lossless WebP) | Match display | JPG often makes text look slightly “dirty” |
| Transparent logos/icons | PNG (or WebP) | As needed | Don’t convert to JPG if you need transparency |
If you want a quick sanity check: open the compressed image and ask yourself, “Would I notice this if I wasn’t hunting for flaws?” If the answer is no, you’re probably good.
A no-drama batch workflow inside File Gulp
If you’re trying to standardize a folder of images (client deliverables, website assets, product photos), this is the routine:
- Resize everything to your target dimensions: Resize Image
- Convert to a web-friendly format:
- Image to WebP (great for mixed inputs)
- or JPG to WebP / PNG to WebP
- Compress to reduce transfer/download size: Compress Image
- Remove metadata for privacy (especially from phone photos): Remove Image Metadata
- Spot-check 5–10 images across the batch (bright, dark, lots of detail, smooth gradients)
If cropping is part of your standardization (say, consistent thumbnails), do that before the final compression:
Web dev corner: responsive images without overthinking it
If you’re serving images on a website, you’ll get better results by combining compression with responsive delivery.
Even a simple setup helps:
- Generate a few widths (like 640 / 960 / 1280 / 1920)
- Serve WebP where possible
- Fall back to JPG for older environments
MDN’s docs on responsive images are worth a skim if you haven’t touched this in a while. (developer.mozilla.org)
Here’s a clean pattern that keeps things compatible:
<picture>
<source srcset="/images/hero-1280.webp" type="image/webp">
<img src="/images/hero-1280.jpg" alt="Hero image">
</picture>I mean, you can absolutely go deeper (multiple srcset sizes, density descriptors, art direction crops), but even this basic approach avoids shipping the heaviest format to everyone.
Common batch compression mistakes (and how to dodge them)
“I compressed first, then resized”
Resizing after compression can amplify artifacts. Resize first, then compress.
“I saved a photo as PNG because I heard it’s higher quality”
PNG is great for sharp edges and transparency. For photos, it’s usually a fast path to bloated files.
If it’s a photo in PNG clothing, switch it:
- PNG to JPG (when transparency isn’t needed)
“I posted client photos with GPS coordinates still attached”
It happens more than people like to admit. If you’re sharing publicly, clean the metadata:
“I recompressed the same JPG five times across revisions”
Each round adds damage. Keep a master. Export fresh delivery copies when needed.
A quick reality check: “compression without losing quality”
People say this phrase a lot, but it depends on what they mean.
- Lossless compression can reduce file size with zero pixel changes (common with PNG workflows).
- Lossy compression changes pixels to save more space—done well, the changes are visually invisible.
So yes, you can often compress images so that your eyes can’t tell the difference. Just don’t promise yourself “zero loss” if you’re using lossy settings.
Try this on your next batch
If you’re staring at a folder of 300 images and procrastinating, do this instead:
- Start with Resize Image to set sane dimensions
- Convert to Image to WebP for web delivery
- Run Compress Image to cut the remaining weight
- Finish with Remove Image Metadata if the images are leaving your control
Small routine, big payoff.