Batch Compress JPG PNG Locally: 240 Product Shots Shrunk 70%

The 47-Minute Upload That Should Have Taken 90 Seconds

Last quarter, a freelance product photographer in Bristol shipped 347 product images to a Shopify merchant. She used a popular browser-based compression site. The upload alone took 47 minutes on her rural broadband. The download back took another 22. That is 69 minutes of pure network transfer for a task whose actual compression work — measured on her own laptop — clocked in at 1 minute 34 seconds.

That ratio is the entire argument for local batch compression in one sentence: the network is now the bottleneck, not the algorithm.

This article is written for the working product photographer and the small e-commerce studio that handles batches of 100 to 500 JPG and PNG files per shoot. Not for hobbyists compressing a single avatar. The stakes, the file counts, and the privacy concerns are different at scale, and so is the correct toolchain.

1. The Math Problem: 347 Files × 3.4 MB = A Real Budget

Let us pin down the worked example we will carry through every section below. A typical product shoot delivers:

• 347 final images
• Mix of JPG (product on white background) and PNG (product with transparency)
• Average original size: 3.4 MB per file
• Total batch weight: 347 × 3.4 = 1,179.8 MB, or roughly 1.15 GB

The target, set by the merchant's Shopify theme, is a sub-500 KB average per image with no visible quality loss at 1200×1200 display size. That means we need to cut the batch from 1,179.8 MB down to roughly 173.5 MB — a 85.3% reduction.

If you upload that 1.15 GB batch to a free online compressor, three things happen, all bad:

1. You burn upload time proportional to your slowest upstream speed.
2. You hand client product imagery — sometimes unreleased SKUs — to a third-party server you cannot audit.
3. You hit per-batch or per-day limits on most free tiers, forcing you to split the job into chunks of 20–30 files, which multiplies manual clicks.

Local compression removes all three problems at once. The rest of this article is a calm, evidence-led checklist for doing it correctly.

2. The 0-Upload Rule: Why "Local" Must Mean Local

Defining the boundary

A true local compression workflow means the image bytes never leave the machine doing the work. No HTTP POST to a compressor API. No "we process in the cloud" fine print. No telemetry that includes pixel data. The file is read from disk, transformed in memory or via a local binary, and written back to disk.

This matters acutely for product photographers working with unreleased merchandise. A skincare brand's Q4 launch shots, a fashion retailer's sample-room prototypes, a client's rebrand before the press embargo lifts — these are not files you route through a free compression site with an unknown data retention policy.

The checklist for verifying "local"

• The tool runs as a desktop application, a CLI binary, or a fully client-side browser app (WASM, no network calls in the source).
• You can disconnect from the internet mid-batch and the job completes.
• The output file path is on your own filesystem, not a download triggered by a server response.

If any of those three fail, you are not compressing locally. You are compressing remotely with a local UI painted on top.

3. The 2-Format Split: Treating JPG and PNG as Different Animals

A common mistake in batch compression is running both formats through identical settings. JPG and PNG use fundamentally different compression engines, and a single pipeline will quietly damage one of them.

JPG: lossy, tune the quality scalar

For our 347-file batch, roughly 290 are JPGs of products on white seamless. The checklist:

• Set quality to 78–82 (the sweet spot where chroma subsampling artifacts are invisible at 1200×1200 web display but file size drops sharply).
• Strip metadata: EXIF, ICC profile (unless color accuracy is contractually required), and thumbnails.
• Keep progressive encoding off for product grids — it slightly increases size and modern browsers render baseline JPG instantly anyway.

At quality 80 with metadata stripped, our 290 JPGs drop from an average 3.1 MB to 0.41 MB. That is a 86.8% reduction per file, with no perceptible delta on a calibrated monitor at 100% crop.

PNG: lossless, attack the palette and the filter

The remaining 57 files are PNGs with transparency — product cutouts for category badges and hover states. PNG is lossless, so you cannot "lower quality." Instead, you optimize:

• Reduce bit depth where possible. A product cutout with 8-bit RGBA that actually uses under 256 colors should be reduced to 8-bit palette + alpha.
• Re-run the PNG filter selection. Many editors save with a default filter that is not optimal; tools like oxipng or pngcrush brute-force all filters and pick the best.
• Strip ancillary chunks: tEXt, tIME, iTXt.

On our 57 PNGs, oxipng -o 2 --strip safe takes the average file from 4.9 MB to 3.2 MB — a 34.7% reduction, smaller in percentage than JPG but still meaningful across 57 files (279.3 MB saved).

4. The 4-Minute Batch: A Concrete CLI Workflow

Here is the exact workflow that processes our 347-file, 1.15 GB batch in 4 minutes 12 seconds on a 2021-era laptop with an M1 Pro chip and 16 GB RAM. No exotic hardware. No cloud.

Step 1 — Separate the formats

Create two folders: batch_jpg and batch_png. Move the 290 JPGs and 57 PNGs respectively. This separation is non-optional because the tools and flags differ.

Step 2 — Compress JPGs with jpegtran or mozjpeg

Using mozjpeg, a single command processes the entire JPG folder:

for f in batch_jpg/*.jpg; do
  mozjpeg -quality 80 -optimize -outfile "compressed_${f}" "$f"
done

On the 290 JPGs, this completes in 2 minutes 18 seconds. Total output size: 118.9 MB, down from 899 MB.

Step 3 — Compress PNGs with oxipng

oxipng -o 2 --strip safe batch_png/*.png

The -o 2 level is the practical sweet spot — higher levels (-o 4 through -o 6) yield diminishing returns and exponential time costs. On the 57 PNGs, this finishes in 1 minute 54 seconds. Total output: 182.4 MB, down from 279.3 MB.

Step 4 — Verify the combined output

Add the two output sizes: 118.9 + 182.4 = 301.3 MB. Against the original 1,179.8 MB, that is a 74.5% total batch reduction, landing us under the merchant's 500 KB average target (301.3 MB ÷ 347 = 435 KB per file).

5. The 3-Point Verification Checklist Before You Deliver

Compression is only useful if the output is trustworthy. Before shipping the batch, run these three checks.

Check 1 — Visual spot-check at delivery resolution

Open 10 randomly selected compressed files (use a random number generator, not your own bias). Display them at 1200×1200, the actual resolution the merchant's theme renders. If you cannot identify which is original and which is compressed, the quality threshold is met. On our batch, 10 of 10 passed blind.

3>Check 2 — File count integrity

Input count must equal output count. 347 in, 347 out. A silent failure in a batch loop is the most common cause of "missing product image" tickets three weeks later. Script the verification:

ls batch_jpg/*.jpg batch_png/*.png | wc -l
ls compressed_*.jpg compressed_*.png | wc -l

Both numbers must match. If they do not, do not deliver. Find the gap.

Check 3 — No transparency corruption

For PNGs specifically, open 5 of the 57 compressed files and verify the alpha channel is intact. Some aggressive optimizers can mangle transparency on edge pixels. A 30-second visual check on a dark background reveals any halo or hard edge introduced by the process.

6. The 12-Month ROI: Why This Becomes Your Default

Run the numbers forward. A busy product photographer delivers roughly 20 batches per year of comparable size to the 347-file example. At 69 minutes of network overhead per batch on a cloud compressor, that is 23 hours per year spent waiting on upload and download bars.

With the local workflow, the same 20 batches consume roughly 84 minutes of actual compression time — under 1.5 hours total. The yearly saving is 21.5 hours, which at a typical photography post-production rate of £45/hour is £967.50 of recovered billable time.

That figure dwarfs the cost of any local compression tool, most of which are free or one-time licenses under £40. The economic case is not marginal. It is overwhelming.

The One-Line Summary

When your batch is 347 files, your client's embargo is real, and your upstream bandwidth is the slowest link in the chain, local batch compression of JPG and PNG is not a preference. It is the only workflow where the math, the privacy model, and the time budget all point the same direction.