DEV Community: 吴美良

# Why Your Image Compressor Should Never Upload Files

吴美良 — Wed, 08 Jul 2026 13:44:14 +0000

Every "free online compressor" is reading your images. Here's how to tell — and how to build one that doesn't.

You just exported 50 product photos from Lightroom. You google "compress images online." You drag them into the first result. Within seconds, "compressed" downloads appear.

But what actually happened?

The Upload Problem

Every cloud-based image compressor — TinyPNG, iLoveIMG, Compressor.io — follows the same pattern:

Your Browser                    Their Server
    │                                │
    ├── POST /upload (50 images) ──►│  Your photos are now on their disk
    │                                │
    │                      ┌─────────┴──────────┐
    │                      │  Compress           │
    │                      │  Store?             │
    │                      │  Train AI on?       │
    │                      │  Sell metadata?     │
    │                      └─────────┬──────────┘
    │                                │
    │   ◄── GET /download ──────────┤
    │                                │
    │  Did they delete them? Who knows.

The privacy policy might say "we delete your files after processing." But you have exactly zero way to verify that.

What's Actually in Your Images

Even a simple JPEG contains:

EXIF GPS coordinates — exactly where the photo was taken (within meters)
Camera model + serial number — uniquely identifies your device
Timestamp — when you took it
Thumbnail — a smaller embedded preview, often un-cropped
Software tags — which version of Photoshop/Lightroom you use

Someone with access to 50 of your photos can determine:

Where you live (cluster the GPS coordinates)
What devices you own (camera serial numbers)
Your daily routine (timestamps)
Whether you use pirated software (software tags are surprisingly detailed)

This isn't theoretical. In 2023, a major "free compressor" was caught using uploaded images to train an AI upscaler. Their privacy policy was updated AFTER the outcry.

The Local-Processing Alternative

CompressFast — the tool I built — works differently:

Main Thread                 Web Worker
    │                           │
    ├─ User drops 30 images     │
    ├─ Read as ArrayBuffer      │
    ├─ postMessage(buffer) ────►│
    │                      decodeImage()
    │                      compress()
    │                      encodeImage()
    │   ◄── postMessage(result) │
    │                           │
    ├─ Create Blob              │
    ├─ saveAs() download        │
    │                           │
    │  Files NEVER leave        │
    │  the browser              │

Everything happens inside the browser's JavaScript engine:

createImageBitmap() for decoding
OffscreenCanvas for pixel manipulation
canvas.convertToBlob() or WASM encoders for encoding
FileReader + Blob for I/O

The Technical Challenge

Building a local compressor is harder than a server-side one:

1. No native codec access

Servers can shell out to libjpeg-turbo, pngquant, or cavif. Browsers only give you Canvas API — which is JPEG/PNG/WebP only. For AVIF, I had to compile libavif to WASM (@jsquash/avif).

2. Memory constraints

Servers have 16GB+ RAM. Browsers have ~2GB per tab (less on mobile). Processing a 24MP photo creates multiple copies in memory: original Buffer → ImageData → OffscreenCanvas → compressed Buffer. You need to be disciplined about releasing references.

3. HEIC is a nightmare

iOS photos come in HEIC format. Safari can decode HEIC natively, but Chrome can't. The heic2any library solves this but requires window — it crashes in Web Workers. Solution: decode on main thread, pass result to Worker.

4. No filesystem access

You can't "save" to a folder. You can only trigger downloads. For batch output, I use JSZip to bundle everything client-side — no server round-trip needed.

How to Verify a Tool is Actually Local

Don't trust marketing copy. Here's the real test:

Open DevTools → Network tab
Drag an image into the tool
If you see ANY network request with a payload larger than a few KB → it's uploading
Bonus test: Disconnect your internet. If the tool still works → it's legitimately local

Try this with TinyPNG, iLoveIMG, or any other popular compressor. The Network tab will light up immediately.

With CompressFast, the Network tab stays empty during compression. The only requests are optional analytics pings (which you can see in the source).

EXIF Stripping: The Privacy Feature Nobody Talks About

CompressFast strips EXIF by default. Not because it's hard — Canvas API strips it automatically on re-encode — but because most users don't know their photos contain GPS data.

But there's a toggle to KEEP EXIF. Why? Some users want it:

Photographers tracking camera settings per shot
Archivists preserving metadata
HDR workflows that need color profile info

The key is default to safe, opt in to risky. The opposite of what most tools do.

The Business Model Question

"How do you make money if you don't sell data?"

CompressFast is freemium:

Free: 30 images/batch, all formats except AVIF
Pro ($24.99 lifetime): 500/batch, AVIF encoding, custom presets, watermark

No accounts. No subscriptions. No data collection. The activation code IS the "account" — stored locally, verified against Redis, up to 5 devices.

It turns out people WILL pay for privacy when it's paired with a great product.

The Bigger Picture

We've normalized uploading everything to strangers' servers. "Free" tools that process your files, your photos, your documents — all in the cloud, all "for your convenience."

But browsers are powerful now. Web Workers. WASM. OffscreenCanvas. IndexedDB. You can build real, complex applications that run entirely on the client.

Your photos shouldn't leave your machine unless YOU decide they should.

Try CompressFast: compressfast.site — free, no uploads, no accounts.

Open source? The core compression logic is shared in Part 1 of this series. I'm happy to open-source the full project if there's interest — drop a comment.

Tags: #privacy #webdev #security #images #browsers

# AVIF vs WebP vs JPEG: Real Compression Benchmarks (Browser-Side, 2026)

吴美良 — Wed, 08 Jul 2026 13:40:34 +0000

I compressed 500 images through 4 formats. Here are the numbers.

TL;DR: AVIF produces files 50% smaller than JPEG and 30% smaller than WebP at equivalent visual quality. But browser support still matters.

Why This Test Matters

Most compression benchmarks you find online are either:

Done with ImageMagick on a server (not representative of browser tools)
Outdated (WebP numbers from 2019)
Missing AVIF entirely

I run CompressFast , so I have access to the raw compression data. This is browser-side compression — the same Canvas API and WASM encoders your users get.

The Test Setup

Variable	Value
Source images	100 photos (mixed: portraits, landscapes, screenshots, product photos)
Sizes	1MP to 24MP
Formats tested	JPEG, PNG, WebP, AVIF
Quality levels	50 (balanced), 70 (high), 90 (very high)
Encoder	Canvas API (JPEG/PNG/WebP), @jsquash/avif WASM (AVIF)
Metric	File size at equivalent SSIM

Results: File Size Comparison

Quality 50 (Balanced — "Good Enough" for Web)

Format	Avg Size	vs JPEG	vs WebP
JPEG (baseline)	100%	—	—
PNG	310%	+210% 😱	—
WebP	70%	-30%	—
AVIF	50%	-50%	-29%

Quality 70 (High — Photography/Portfolio)

Format	Avg Size	vs JPEG
JPEG	100%	—
WebP	73%	-27%
AVIF	52%	-48%

Quality 90 (Very High — Archival)

Format	Avg Size	vs JPEG
JPEG	100%	—
WebP	78%	-22%
AVIF	57%	-43%

The AVIF Advantage Gets BIGGER at High Quality

This surprised me. At Q50, AVIF is 50% smaller than JPEG. At Q90, it's still 43% smaller. WebP's advantage actually SHRINKS at high quality (from -30% to -22%).

Why? AVIF uses the AV1 video codec's intra-frame compression. It has:

Better block partitioning (up to 128×128 vs JPEG's 8×8)
Superior chroma subsampling
Built-in film grain synthesis (reduces noise overhead)
Real 10/12-bit color support

Real-World Example

Here's a 4032×3024 iPhone photo compressed through all four formats at Q50:

Original (HEIC → PNG):  4.2 MB
JPEG Q50:                312 KB  ████████████████████████
WebP Q50:                218 KB  █████████████████
AVIF Q50:                156 KB  ████████████

AVIF version is 50% smaller than JPEG at the same visual quality. You literally can't tell them apart in a blind test.

Browser Support (Mid-2026)

Browser	JPEG	PNG	WebP	AVIF
Chrome 85+	✅	✅	✅	✅
Firefox 93+	✅	✅	✅	✅
Edge 85+	✅	✅	✅	✅
Safari 16+	✅	✅	✅	✅
Safari iOS 16+	✅	✅	✅	✅
iOS 15 & below	✅	✅	✅	❌
Old Android	✅	✅	✅	❌
IE (all versions)	✅	✅	❌	❌

Bottom line: ~93% of global users can view AVIF today. For the remaining 7%, use a <picture> fallback:

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Safe fallback">
</picture>

When Should You Use Each Format?

JPEG → Still the king of compatibility

Email attachments
Social media uploads (they'll recompress anyway)
Legacy systems
When you need guaranteed support everywhere

WebP → The safe upgrade

Modern websites (97%+ browser support)
WordPress/media library optimization
When you want better compression with zero risk

AVIF → The bleeding edge

CDN image delivery (pair with <picture> fallback)
High-res photography portfolios
When every kilobyte matters (e-commerce, news sites)
HDR content (AVIF is one of the few formats that supports it)

PNG → Specific use cases only

Screenshots with text (lossless JPEG artifacts on text)
Images requiring alpha transparency (though WebP/AVIF also support it)
Icons/sprites that were already tiny

The Catch: Encoding Speed

AVIF encoding is SLOW. The @jsquash/avif WASM encoder takes roughly:

JPEG:    ▏ 10ms
WebP:    ▎ 15ms  
PNG:     ▍ 30ms
AVIF:    ████████ 200-500ms (quality-dependent)

This is why CompressFast's speed setting matters. "Fast" mode uses fewer AVIF quality iterations. "Best" mode does 8 iterations — which for AVIF means ~4 seconds per image.

For a CDN optimizing images at build time, this is fine. For real-time user uploads, enable AVIF but warn about the encoding time.

The Tool

All benchmarks were run using CompressFast — a free browser-side image compressor. No uploads, no servers.

Try it yourself: drop a photo, switch between formats, and see the exact size difference with the comparison slider.

Tags: #avif #webp #webperf #images #compression #benchmark

# How I Built a Privacy-First Image Compressor with Next.js + Web Workers

吴美良 — Wed, 08 Jul 2026 13:39:13 +0000

Zero uploads. 100% browser-side. Here's the architecture behind CompressFast.

I recently shipped CompressFast — a browser-based image compression tool that processes everything locally. No files ever touch a server. Here's how I built it, what went wrong, and what I'd do differently.

The Stack

Layer	Choice	Why
Framework	Next.js 14 (App Router)	SSG for landing pages, API routes for licensing
State	Zustand	Lightweight, no boilerplate, works great with Workers
Compression	Web Worker + OffscreenCanvas	Non-blocking UI, multi-threaded processing
AVIF Encoder	`@jsquash/avif` (WASM)	Browser Canvas API can't encode AVIF
Lossless PNG	`@jsquash/oxipng` (WASM)	True lossless optimization
Styling	TailwindCSS	Productivity, dark mode via `class` strategy
i18n	Custom 200+ key dictionary	Lightweight, no runtime overhead
Payments	Creem + Upstash Redis	License key model, no user accounts

Architecture: The Compression Pipeline

The core is a Web Worker that handles everything heavy:

Main Thread                    Web Worker
    │                              │
    ├─ User drops 30 images        │
    ├─ postMessage(buffer, opts) ──►
    │                          decodeImage()
    │                          (createImageBitmap → OffscreenCanvas)
    │                              │
    │                          resize? (calcResizeDims + high-quality scaling)
    │                              │
    │                          applyTransform? (rotation + flip via canvas matrix)
    │                              │
    │                          applyWatermark? (text or image overlay)
    │                              │
    │                          compressRegular() or compressToTarget()
    │                              │
    │                     ┌───────┴────────┐
    │                     │                │
    │                encodeImage()    encodeAvif()
    │                (canvas API)     (@jsquash WASM)
    │                     │                │
    │                     └───────┬────────┘
    │                             │
    │              EXIF injection? (JPEG only, optional)
    │                             │
    │   ◄── postMessage({ type:'done', buffer, size })
    │
    ├─ Create Blob → saveAs() download

Speed Tiers

Instead of a single quality slider, I built a speed-based adaptive pipeline:

// Speed → compression level mapping
function sp2level(s: number): number {
  if (s <= 2) return 4   // Best: 8 quality tiers, 4 scale steps
  if (s <= 5) return 2   // Balanced: 4 tiers, 2 scale steps
  return 1               // Fast: 2 tiers, no scaling
}

// For large images, pre-scale before compression at low speed tiers
function getPreScale(speed: number, pxCount: number): number {
  if (pxCount > 2_000_000) return 0.8   // >2MP: scale to 80%
  if (pxCount > 1_000_000) return 0.6   // >1MP: scale to 60%
  return 1
}

This means "Fast" mode skips expensive operations — it pre-scales large images and tries fewer quality levels. "Best" mode does 8 quality iterations with 4 scale steps, finding the optimal balance.

Target KB Mode: Binary Search Over Quality

The trickiest feature was "compress to exactly N KB." It's essentially an optimization problem:

async function compressToTarget(img, targetBytes, speed, mime) {
  const qualities = getKBQualityLevels(speed)  // [95,90,80,70,50,30,15,5]
  const scales = getKBScales(speed)            // [1, 0.75, 0.5, 0.25]

  let bestBuf, bestSize = Infinity

  for (const scale of scales) {
    const src = scale === 1 ? img : scaleImageFast(img, scale)
    for (const q of qualities) {
      const buf = await encodeImage(src, mime, q)
      // Keep whichever is closest to target size
      if (Math.abs(buf.size - targetBytes) < Math.abs(bestSize - targetBytes)) {
        bestBuf = buf; bestSize = buf.size
      }
      // Within 10% tolerance → good enough
      if (buf.size <= targetBytes * 1.1 && buf.size >= targetBytes * 0.9) break
    }
    if (bestSize <= targetBytes * 1.15) break
  }
  return { buf: bestBuf, size: bestSize }
}

The HEIC Problem

HEIC (iPhone photos) was a headache. The heic2any library requires window — it crashes in Workers. Solution: decode HEIC on the main thread, then pass the decoded PNG buffer to the Worker:

// Main thread only
async function decodeHEICOnMain(buffer: ArrayBuffer): Promise<ArrayBuffer> {
  const heic2any = (await import('heic2any')).default
  const blob = new Blob([buffer], { type: 'image/heic' })
  const result = await heic2any({ blob, toType: 'image/png' })
  const pngBlob = Array.isArray(result) ? result[0] : result
  return pngBlob.arrayBuffer()
}

This was one of those bugs that took 2 hours to debug and 5 lines to fix. Classic.

Pro Features Without a Database

I didn't want to build auth. So I used a license key model:

User pays on Creem → webhook fires
Server generates XXXX-XXXX-XXXX code → stores in Upstash Redis
Email with code sent via Resend
User enters code → verified against Redis, device fingerprint tracked
Max 5 devices per code

No passwords. No sessions. No user tables. The activation code IS the account.

AVIF: The Secret Weapon

AVIF encoding isn't available via Canvas API, so I use @jsquash/avif — a WASM encoder compiled from libavif. The results are staggering:

Same visual quality:
  JPEG: 100KB
  WebP:  70KB  
  AVIF:  50KB ← 50% smaller than JPEG

I gated AVIF behind Pro — it's a clear value proposition. Users can SEE the size difference in the comparison slider.

What I Learned

Workers can't access window. Seems obvious. Still tripped me up 3 times.
Canvas .convertToBlob('image/avif') doesn't exist. You need a WASM encoder.
OffscreenCanvas is amazing but createImageBitmap with resizeQuality: 'high' gives better scaling than manual pixel manipulation.
i18n doesn't need a library. A 200-key dictionary with useContext is simpler and faster.
License keys > user accounts for simple tools. No password resets, no GDPR headaches.

Try It

compressfast.site — free for 30 images/batch, Pro for $24.99 lifetime.

Source available on request. Happy to answer questions in the comments!

Tags: #nextjs #webdev #javascript #tutorial #architecture