DEV Community: 吴美良

# HEIC to JPG: How to Convert iPhone Photos Without Installing Anything

吴美良 — Fri, 21 Aug 2026 05:10:33 +0000

If you've ever tried to send an iPhone photo to a Windows PC, a form upload, or an older app, you've probably hit the "HEIC file won't open" wall. Apple switched the default camera format from JPEG to HEIC back in 2017, and it's still quietly breaking workflows everywhere.

Here's what's going on and the fastest way to fix it — no app installs, no uploads to someone else's server.

What is HEIC, anyway?

HEIC is a container format built on the HEIF standard (High Efficiency Image File Format). Under the hood it uses HEVC — the same codec that powers 4K video — which is why it stores photos at roughly half the size of an equivalent JPEG at the same quality.

The catch: HEVC is patent-encumbered, and support outside Apple's ecosystem is patchy. Windows needs a paid codec extension, some CMSes reject it outright, and plenty of image editors still can't read it.

Why JPG is still the safe default

JPG is the one format that opens absolutely everywhere. If a photo is going to leave Apple's ecosystem — email, a client portal, a print shop, a WordPress upload — JPG is the lowest-friction choice. You give up a bit of compression efficiency, and you'll want to strip the EXIF metadata before publishing, but compatibility is bulletproof.

The 30-second conversion (works right in your phone browser)

You don't need a desktop app or a "convert HEIC" website that uploads your photos to a server. Conversion is a browser-native task now:

Open an HEIC to JPG converter in any modern browser — phone or desktop.
Drop your HEIC files in (or tap to select from your camera roll). You can batch up to 30 at once.
Download the JPGs — individually or as one ZIP.

Because it runs entirely on-device with Web Workers, your photos never leave your phone. You can even put it in airplane mode and watch it keep working — that's the test for whether a tool is actually local.

HEIC → JPG isn't your only option

Depending on what you're doing, two other conversions are worth knowing:

HEIC → PNG — when you need lossless and transparency, e.g. for a logo or a screenshot you'll edit later. See the HEIC to PNG converter.
HEIC → WebP — when the destination is the web. WebP is ~25–35% smaller than JPEG at the same quality, which matters for page speed. See the HEIC to WebP converter.

Bottom line

HEIC is great on your iPhone and painful everywhere else. When a photo needs to travel, convert it to JPG (or WebP for the web) first — and do it in a way that keeps the file on your device. It's faster and more private than the upload-first alternatives.

# Batch Compress Images Without Uploading Them: A Privacy-First Workflow

吴美良 — Fri, 21 Aug 2026 05:09:46 +0000

"Free online image compressor" is one of the most loaded phrases on the internet. A surprising number of those tools make their money not by charging you, but by keeping a copy of every image you "compress" — photos of your ID, your family, your product mockups — on their servers.

You don't have to make that trade. Browser-side compression has been fast enough for years, and the workflow below runs entirely on your device.

The upload test

Before you trust any compressor with a real file, run this 15-second test:

Open the tool.
Turn off Wi-Fi / mobile data.
Compress an image.

If it still works, the compression is happening locally in Web Workers — your files never left the device. If it stalls at "uploading…", close the tab.

The batch workflow

Here's the order of operations I use for a folder of images, from biggest win to smallest:

1. Resize first

Compressing a 4000×3000 photo without resizing is like dieting by wearing lighter shoes. Resize to the actual display size (or 2× for retina) and you'll often cut 70–90% of the weight before compression even starts. Use a batch resize step if the whole folder is oversized.

2. Compress in batch

Drop the whole folder into a batch image compressor and let it process up to 30 files at once. For specific formats there are dedicated pages — PNG, JPEG, and GIF — each tuned for that format's codec.

3. Strip metadata

Every phone photo carries EXIF data: GPS coordinates, device model, timestamp, sometimes a thumbnail. It's dead weight (10–50 KB each) and a genuine privacy leak if you publish originals. Strip EXIF before anything goes live.

4. Download as one ZIP

Good batch tools let you pull everything back down as a single ZIP rather than clicking download 30 times.

Why "no upload" matters beyond privacy

It's also faster. There's no round-trip to a server and back — the processing starts the instant the file hits your browser. On a slow connection or a big batch, that's the difference between seconds and minutes.

# Convert Images to WebP in Seconds (PNG, JPG, GIF, AVIF)

吴美良 — Fri, 21 Aug 2026 05:09:01 +0000

WebP is quietly the most important image format on the modern web: it's 25–35% smaller than JPEG at the same visual quality, supports transparency, and has 96%+ browser support across Chrome, Firefox, Safari, and Edge. If you're still serving JPEGs or PNGs on a production site, converting to WebP is one of the cheapest page-speed wins available.

Here's the format-conversion map and how to do each conversion in your browser.

The WebP conversion cheat sheet

From	Why convert	Browser tool
PNG	Transparency + much smaller files	PNG to WebP
JPEG	Photos: same quality, ~30% smaller	JPG to WebP
GIF	Animated content that's smaller than GIF	GIF to WebP
AVIF	Fallback for older browsers	AVIF to WebP

There's also a general Convert to WebP page if you want to drop in mixed formats and convert everything at once.

What quality setting should you use?

For photos, 75–80% WebP quality is the sweet spot — visually indistinguishable from the source at normal viewing distance, but meaningfully smaller. For logos and line art with hard edges, prefer lossless WebP (or keep PNG) so you don't get the soft halo that lossy compression introduces around high-contrast edges.

When to reach for AVIF instead

WebP isn't the end of the line. AVIF is 30–50% smaller than JPEG — beating WebP — but it's slower to encode and, as of now, slightly less universally supported. A good rule of thumb:

WebP — the safe default for production today.
AVIF — when you have a large image library and you're willing to serve <picture> fallbacks.

If you need to go the other direction — say a client requires JPEG — the WebP to JPG converter handles that too.

One conversion detail that trips people up

WebP supports both lossy and lossless modes, but a lot of "convert to WebP" tools quietly pick one for you. If you're converting a screenshot or UI element and the text looks slightly soft afterward, you're in lossy mode — switch to lossless (or use PNG) and it'll be crisp.

# How to Compress Images for the Web in 2026 (A Practical, No-Nonsense Guide)

吴美良 — Fri, 21 Aug 2026 05:07:52 +0000

Images are still the heaviest thing on almost every web page. According to the HTTP Archive, the median page now ships over 1 MB of images — often half the total page weight. That's not just a speed problem. It's a bounce-rate problem, a Core Web Vitals problem, and (with image-heavy landing pages) a conversion problem.

The good news: compressing images properly is the single highest-leverage performance win you can make, and it doesn't require a design team. Here's the exact workflow I use, in order of impact.

1. Resize first (this is the 80/20 win)

Most people skip this step and go straight to "make the file smaller." Don't.

A 4000×3000 photo from your phone is ~12 megapixels. But it's almost certainly being displayed at 800px wide or less. If you resize it to the actual display size before compressing, you often cut 70–90% of the weight with zero visible quality loss — because you're throwing away pixels nobody can see.

Rule of thumb: never serve an image larger than 2× its display size (for retina screens).

2. Pick the right format

The format you choose matters as much as the compression. The short version:

Photos → WebP (or AVIF if you can afford the encode time)
Logos, icons, screenshots → PNG (or SVG for vector)
Animated content → WebP or GIF
Compatibility-first → JPEG still works everywhere

WebP is the safe default today — 25–35% smaller than JPEG with 96%+ browser support. AVIF is even smaller (30–50% vs JPEG) but slower to encode. If you want the full breakdown with real numbers, I wrote a complete guide on choosing a web image format.

3. Compress with the right loss settings

There are two fundamentally different kinds of compression, and mixing them up is the #1 mistake:

Lossless — no pixels change, ever. PNG via tools like oxipng. Expect 20–60% savings, and it's perfect when every pixel matters (screenshots, line art, logos).
Lossy — throws away detail the eye can't see. JPEG/WebP at 75–85% quality typically saves 50–70% while looking identical at normal zoom.

For a deep dive on the difference — and how to choose — see how to compress images for web.

4. Strip metadata

Every photo from a camera or phone carries EXIF data — GPS coordinates, camera model, timestamp, sometimes a thumbnail. It's pure dead weight (often 10–50 KB per image) and, in the case of GPS, a genuine privacy leak if you serve originals. Strip it before publishing. Always.

5. Do it without uploading your files

One thing I wish more people knew: you don't need to upload your images to a server to compress them. Browser-side compression has been possible for years, and it's dramatically faster (no upload/download round-trip) and more private (your files never leave your device).

The test is simple: open a compression tool, disconnect your internet, and try compressing. If it still works, it's running locally in Web Workers — your images never touched a server.

That's the approach I took when I built CompressFast, a browser-based compressor that handles PNG, JPEG, WebP, AVIF, GIF, BMP, SVG and HEIC, batches up to 30 images, and downloads a ZIP — all on-device.

The email-attachment special case

Compressing for email is a different beast from compressing for the web: you have a hard size ceiling (usually 25 MB, but many corporate servers cap at 10 MB), and the recipient might open it on anything from a 5K monitor to an old Android phone.

The fix is almost always the same two steps: resize the long edge to ~1600px (a 4000px photo is massive overkill for email) and export as JPEG at 75–85%. A 5 MB phone photo becomes ~500 KB. I wrote a dedicated walkthrough on compressing images for email attachments.

Quick checklist

[ ] Resize to actual display size (or 2× for retina)
[ ] Photos → WebP/AVIF, logos → PNG/SVG
[ ] Lossy 75–85% for photos, lossless for screenshots/line art
[ ] Strip EXIF/GPS metadata
[ ] Verify on slow 4G before shipping
[ ] Prefer tools that process locally (no upload)

If you only remember one thing: resize first, then compress. Everything else is optimization on top of that.

"How I Built a Browser Image Compressor That Handles 30 Images at Once"

吴美良 — Sun, 16 Aug 2026 03:18:13 +0000

Most image compressors do the actual work on a server. Mine runs entirely in the browser — 30 images at a time, re-encoded with the Canvas API, on your device. Here's the architecture that makes that possible, and the bugs that nearly broke it.

I built CompressFast to scratch my own itch, and the constraint was non-negotiable: files must never leave the device. That single decision shaped everything downstream.

The architecture: keep the heavy work off the main thread

Re-encoding a 4000×4000 photo is CPU-heavy. If you do it on the main thread, the UI freezes and the browser flags "page unresponsive". So the core is a Web Worker that owns the entire compression pipeline:

Main thread (React)  ←→  Web Worker
   upload / UI              └─ decode → transform → encode → transfer

The main thread handles selection, previews, and state. The worker does:

Decode — createImageBitmap for standard formats, a dedicated path for HEIC
Transform — resize, rotate, flip (applied before encoding, never after)
Encode — canvas.toBlob('image/webp', quality) (and JPEG/PNG/AVIF)
Transfer — the compressed Blob is handed back via postMessage

The key detail: use transferables (ArrayBuffer, not structured-clone of a Blob) wherever you can. For a 30-image batch, that's the difference between instant and a half-second of GC pressure per file.

Auto format detection — the "smart" part

Not every image should be compressed the same way. Photos want lossy WebP; screenshots and logos want lossless PNG. So the worker classifies each file and picks a strategy:

JPEG/photo → WebP, quality 75–82% (the visual-equivalence sweet spot)
PNG/screenshot → lossless (oxipng-style), 20–60% smaller with zero pixel change
GIF → animated WebP (60–80% smaller)
HEIC (iPhone) → decoded first, then treated as a photo

This is why batch mode doesn't need per-file settings — the user drops a folder, and each image gets the right treatment automatically.

Three bugs that took way too long to find

If you're building anything with Web Workers, learn from my scars:

1. A worker can't reference window — even transitively.
I pulled in a library whose module top-level touched window. In the worker context, Webpack's chunk threw ReferenceError: window is not defined, and every compression hung on the spinner with no error in the console. Fix: audit every worker import — grep -r "window\|document" node_modules/<lib> — and keep browser-only libraries on the main thread, passing data to the worker afterward.

2. Integer truncation broke image scaling.
My fast resize path used Math.round(1/ratio) as a pixel step. For large images that truncation pushed the source coordinate past the row width, and the image came out split horizontally with black mosaic at the bottom. Fix: exact floating-point ratios plus a Math.min() bounds guard on every manual pixel loop.

3. An async handler corrupted processing order.
I made the worker's message handler await a transform after encoding. Async handlers don't preserve order — the rotation state got out of sync with the blob. Fix: keep worker message handlers synchronous. Apply transforms at download time, not inside the handler.

Bonus: Cross-Origin-Opener-Policy / Cross-Origin-Embedder-Policy headers will silently block worker scripts in production (they worked fine locally). Test any security header change against a real deployment.

Scaling up to 30 files without melting the tab

Batch mode adds two more concerns:

Throttle re-renders. Resize/compare previews fire on every pointer move. A requestAnimationFrame throttle keeps it at 60fps instead of 300 wasted renders per second.
Memory. Blobs stay in memory until download. Packing the final results into a single ZIP (client-side, jszip) keeps 30 "Download" buttons from becoming 30 separate saves.

The result

A 1920×1080 screenshot goes 2.1 MB → 186 KB WebP (91%) → 102 KB AVIF (95%), all computed on-device with no server round-trip. Batch a whole folder, get one ZIP back.

The whole stack — Next.js, a Web Worker, Canvas, and a ZIP library — costs $0/month to run, because there's no compression server to pay for. That's the real payoff of going browser-side: your users' machines do the work you'd otherwise pay for, and their files never leave their hands.

If you want to try it: compressfast.site — free, 30 files per batch, no account.

What's the worst Web Worker bug you've hit? I'd love to add it to the list.

"Image Optimization: The Complete 2026 Checklist for Faster Websites"

吴美良 — Sat, 15 Aug 2026 04:00:28 +0000

Images are the single biggest performance lever on almost every website. They average over 1MB of every 2MB page — and cutting them down is the fastest way to improve Core Web Vitals and SEO rankings.

I've spent the past few months obsessing over image compression (I built CompressFast to scratch my own itch). Here's the complete, ordered checklist I use on every project.

1. Resize first — it's the single biggest win

A 6000×4000 photo served to a 1200px-wide card is pure waste. Before anything else, resize to the largest size your layout actually displays.

Resizing alone cut my test image from 4.7MB to 1.1MB — a 77% reduction with zero quality change.

2. Pick the right format per image type

This is the mistake I see most often — using one format for everything.

Photos → WebP (30–50% smaller than JPEG) or AVIF (another 30% smaller)
Screenshots / UI → PNG lossless, or WebP lossless
Logos / icons → SVG (vector, tiny, infinitely scalable)
Animated GIFs → animated WebP (60–80% smaller)

3. Compress, don't just convert

Converting PNG → JPEG saves space, but then compressing that JPEG saves even more. Always run a compression pass after conversion. Quality 75–82% is the sweet spot for photos — visually indistinguishable from 100%.

4. Strip metadata

EXIF, GPS coordinates, camera model, editing software tags — all useless for web display and can be 10–30KB per file. Strip it.

5. Use lossless compression for text-heavy images

For screenshots, logos, and anything with sharp edges, lossless tools (like oxipng for PNG) shrink files 20–60% without changing a single pixel. Never run lossy compression on text — it creates ugly artifacts.

6. Lazy-load off-screen images

loading="lazy" (or loading="lazy" via next/image) stops below-the-fold images from blocking your LCP. Combine with width/height attributes to prevent layout shift (CLS).

7. Serve modern formats with fallbacks

Use the <picture> element to serve WebP/AVIF to modern browsers and JPEG as a fallback:

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

Real numbers from my testing

A single 1920×1080 screenshot, compressed:

Step	File size	Reduction
Original PNG	2.1 MB	—
Resize + WebP 75%	186 KB	91%
Resize + AVIF 50%	102 KB	95%

That 91–95% saving is the difference between a 4-second and a sub-1-second page load.

The privacy point most guides skip

Most online compressors upload your files to their server to do the compression. That means your (or your users') images are sitting on someone else's infrastructure. If you're compressing product shots, client work, or anything sensitive, use a tool that runs entirely in the browser — the file never leaves the device.

I built CompressFast exactly for this: browser-side compression, no upload, no account, batch up to 30 files, free. It also auto-detects the right format per image so you don't have to think about steps 2–5.

What's the biggest image optimization win you've found? Drop it in the comments.

webdev #performance #images

# I Built a Smart Image Compressor That Auto-Detects the Best Format

吴美良 — Tue, 11 Aug 2026 04:54:48 +0000

We've all been there — staring at a quality slider, wondering if 70% is too low or 90% is too high. Should this PNG stay as PNG? Should I convert to WebP? What even is lossless?

I got tired of guessing, so I built Smart Compress into CompressFast. Drop any image, it figures out the optimal format and quality automatically.

How It Works

The smart analyzer looks at three things:

1. Format

Each image type gets a different strategy:

Input	Smart Decision	Why
PNG (small, likely logo/icon)	Lossless PNG via oxipng	Pixel-perfect, 20-60% smaller
PNG (large, likely photo)	Convert to WebP 75%	70%+ savings, still looks great
JPEG photo	WebP 75%	25-35% smaller, same quality
JPEG huge (>4MP)	WebP 70% + resize to 1920px	90%+ savings for web
GIF	Animated WebP	60-80% smaller, animation preserved
HEIC	WebP	Universal compatibility
SVG	Keep as-is	Vector doesn't need compression

2. Dimensions

If an image is over 2 megapixels, Smart suggests resizing to 1920px wide. Most websites display images at 1200px max — those extra pixels are just wasted bytes.

3. File Size

Larger files get more aggressive compression. A 10MB photo gets different treatment than a 200KB icon.

The Code

The analysis engine is dead simple — just a function that takes file metadata and returns optimal settings:

function analyzeFile(file: FileMeta): SmartRecommendation {
  const pixels = (file.width && file.height) ? file.width * file.height : 0
  const isLarge = pixels > 2_000_000 || file.originalSize > 1_000_000
  const isHuge = pixels > 4_000_000 || file.originalSize > 5_000_000

  if (file.type === 'image/png') {
    if (isHuge) {
      return {
        quality: 75, outputFormat: 'webp',
        resizeWidth: pixels > 2_000_000 ? 1920 : 0,
        reason: 'Large PNG → WebP (photo/screenshot, 70%+ savings)'
      }
    }
    return {
      quality: 100, outputFormat: 'png', lossless: true,
      reason: 'PNG lossless (oxipng — pixel-perfect, 20-60% smaller)'
    }
  }

  if (file.type === 'image/jpeg') {
    return {
      quality: 75, outputFormat: 'webp',
      reason: 'JPEG → WebP 75% (25-35% smaller, same quality)'
    }
  }
  // ... more format handlers
}

The key insight: most images don't need custom settings. A JPEG photo is a JPEG photo. The heuristics are simple because the use cases are predictable.

The UI

Instead of hiding this behind a settings panel, I put it front and center — a purple "Smart" button right next to the existing Max / Balanced / Best presets:

┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐
│   📦     │ │   ⚖️     │ │   ✨     │ │   🧠 Smart   │
│   Max    │ │ Balanced │ │   Best   │ │   Auto       │
└──────────┘ └──────────┘ └──────────┘ └──────────────┘

Clicking Smart shows a summary panel explaining exactly what it chose and why. No black box — users can see the reasoning and override if they want.

Privacy: Everything Runs Locally

Like everything in CompressFast, the Smart analysis runs entirely in the browser. The file metadata (format, dimensions, size) is read locally — no data ever touches a server. You can unplug your internet after the page loads and Smart Compress still works.

This is the whole philosophy of the project: compression is a solved problem, but most online tools upload your files to a server first. We do everything client-side with Web Workers and WebAssembly.

Try It

Smart Compress is live now at compressfast.site. Free, no signup, no upload. Drop an image and click the purple Smart button.

If you're curious about the full tech stack (Next.js 14, Zustand, oxipng WASM, Creem payments — all for $0/month), I wrote about it here.

I Built a CLI Image Compressor — 73% Smaller in 0.1s

吴美良 — Mon, 03 Aug 2026 15:45:39 +0000

I just shipped compressfast — a command-line image compressor that runs entirely on your machine. No uploads, no API
keys, no limits.

One command:
npx compressfast photo.jpg --quality 80

What it does:

Compress JPEG, PNG, WebP, AVIF
Batch process entire folders
Resize while compressing
Watch mode for automatic processing
All local — files never leave your machine

Real results:
141.6 KB → 37.4 KB (-73.6%)
Time: 0.1s

Built with: Sharp (libvips) — the fastest image processing library for Node.js.

npm: npmjs.com/package/compressfast
GitHub: github.com/WML123270/compressfast

Try it: npx compressfast --help
🔗 Try it: https://compressfast.site — free, no upload, 8 formats supported.

# I Built a $0/month SaaS — Full Stack Breakdown

吴美良 — Sun, 02 Aug 2026 03:49:15 +0000

3,700+ images compressed. 178 users. 1 Pro sale. Total monthly hosting bill: $0.00.

I built CompressFast — a privacy-first image compressor that runs entirely in the browser. No server-side processing. No uploads. No database costs.

Here's exactly how the stack works, why it costs nothing, and what I'd change.

The $0 Stack

Layer	Service	Cost
Hosting	Vercel (Hobby)	$0
DNS	Cloudflare	$0
Database	Upstash Redis (free tier)	$0
Email	Resend (100/day free)	$0
Payments	Creem (5% per sale)	$0 fixed
Analytics	Vercel Analytics (free tier)	$0
Domain	compressfast.site	~$3/yr
Total monthly burn		$0.00

The only real cost is the domain renewal. Everything else rides on generous free tiers.

Architecture: Why There's No Server Bill

The key insight: image compression doesn't need a server.

User's browser
    │
    ├─ Page loads (static HTML from Vercel CDN)
    ├─ User drops 30 images
    ├─ Web Workers spawn → Canvas API compresses locally
    ├─ Blob URLs generated → ZIP created client-side
    └─ Download starts instantly

No upload. No backend processing queue. No temporary storage. The browser does everything.

The only backend code is licensing

/api/create-license  → Generate activation code → Store in Redis
/api/verify-license  → Check code validity → Track device fingerprint
/api/creem           → Webhook: payment → issue license → email via Resend
/api/resend-license  → "Forgot your code?" → email it back

Three tiny API routes. Redis stores license keys + device IDs + stats. That's it.

Multi-Worker Pool (0 Cost, 4x Speed)

Instead of spawning/destroying workers per task, I keep a pool alive:

const POOL_SIZE = Math.min(4, navigator.hardwareConcurrency || 2)
const workers: Worker[] = []

for (let i = 0; i < POOL_SIZE; i++) {
  const w = new Worker(new URL('./worker.ts', import.meta.url))
  workers.push(w)
}

// Round-robin dispatch — no load balancer needed
function dispatch(task: CompressTask): Promise<CompressResult> {
  const worker = workers[taskIndex++ % POOL_SIZE]
  return new Promise(resolve => {
    worker.onmessage = (e) => resolve(e.data)
    worker.postMessage(task.buffer, [task.buffer]) // transferable = zero-copy
  })
}

postMessage(buffer, [buffer]) with transferable objects means zero-copy handoff. The buffer is literally moved, not cloned. 2x faster for large images.

The Compression Pipeline (All Client-Side)

┌─────────────────────────────────────┐
│         Web Worker Pipeline          │
├─────────────────────────────────────┤
│ 1. decodeImage()                    │
│    createImageBitmap → OffscreenCanvas
│                                     │
│ 2. resize?                          │
│    calcResizeDims + multi-step scale │
│                                     │
│ 3. transform? (rotation + flip)     │
│    Canvas matrix transform           │
│                                     │
│ 4. watermark? (text or image)       │
│    Overlay render                    │
│                                     │
│ 5. encode()                         │
│    Canvas API: JPEG/WebP/PNG        │
│    WASM: AVIF (@jsquash), PNG (oxipng) │
│                                     │
│ 6. postMessage back to main thread  │
└─────────────────────────────────────┘

Full pipeline runs in 50-200ms per image depending on size and format.

License Keys Instead of User Accounts

I did NOT want to build auth. So the Pro model is dead simple:

User pays Creem ($24.99 lifetime)
    → Webhook fires
    → Server: generate "XXXX-XXXX-XXXX" code
    → Store in Redis: code → {email, devices[], created_at}
    → Resend: email with activation code
    → User enters code in app
    → Verified, device fingerprint registered
    → Max 5 devices per code

No passwords. No sessions. No user table. No GDPR headaches. The activation code IS the account.

SEO Landing Pages (11 Pages, $0 Hosting)

11 SEO tool pages pre-rendered at build time. Each page targets a specific keyword:

Page	Target
/compress-png	"compress PNG online"
/compress-jpeg	"compress JPEG online"
/compress-webp	"WebP compressor"
/compress-svg	"SVG optimizer"
/remove-metadata	"remove EXIF data"
/vs-tinypng	"TinyPNG alternative"
...	(6 more)

All static HTML. Vercel CDN handles them globally for free. Google is slowly indexing them.

Real Numbers (After 1 Month)

Metric	Value
Total PV	850
Total UV	178
Images compressed	3,716
Pro sales	1 ($24.99)
Monthly cost	$0.00

Not retiring on it. But it proves the model works: $0 burn rate means every sale is pure profit.

What I'd Do Differently

SEO pages earlier. They're low effort, high leverage. Should have been day 1.
Start Twitter sooner. Build-in-public compounds. I started late.
Don't spend 3 hours debugging Worker window access. It's always the same bug.

The Stack in One Line

Next.js + Web Workers + Canvas API + Upstash Redis + Creem + Vercel = $0/month SaaS.

No servers. No uploads. No excuses.

compressfast.site · GitHub

Tags: #webdev #javascript #nextjs #saas #buildinpublic

I Built a $0/month SaaS — Full Stack Breakdown

吴美良 — Tue, 28 Jul 2026 03:10:18 +0000

How CompressFast runs on zero infrastructure cost while handling thousands of image compressions.

The $0 Stack

┌──────────────────┬──────────────────────────┬───────────────────┐
│ Layer │ Technology │ Cost │
├──────────────────┼──────────────────────────┼───────────────────┤
│ Frontend │ Next.js 14 (App Router) │ $0 (Vercel Hobby) │
├──────────────────┼──────────────────────────┼───────────────────┤
│ Image Processing │ Canvas API + Web Workers │ $0 (client-side) │
├──────────────────┼──────────────────────────┼───────────────────┤
│ State Management │ Zustand │ $0 │
├──────────────────┼──────────────────────────┼───────────────────┤
│ Compression WASM │ @jsquash/oxipng + avif │ $0 │
├──────────────────┼──────────────────────────┼───────────────────┤
│ Payments │ Creem (one-time) │ % of sale only │
├──────────────────┼──────────────────────────┼───────────────────┤
│ License DB │ Vercel KV (Redis) │ $0 (free tier) │
├──────────────────┼──────────────────────────┼───────────────────┤
│ Analytics │ Custom API + Vercel KV │ $0 │
├──────────────────┼──────────────────────────┼───────────────────┤
│ Total │ │ $0/month │
└──────────────────┴──────────────────────────┴───────────────────┘

Why Client-Side?

The key insight: image compression is CPU-bound, not I/O-bound. Modern browsers have excellent Canvas APIs. You don't
need a server to resize or re-encode an image.

No upload bandwidth — files stay on device
Instant processing — zero network round-trip
Privacy-first — a real differentiator
Infinite scale — each user brings their own CPU

The Compression Pipeline

User drops file
↓
Main thread: detect format
↓
Web Worker pool (4 workers, round-robin):
- SVG: regex-based text optimization
- HEIC: main-thread decode → Worker
- Raster: decode → resize → quantize → encode
Optional: watermark, rotation, flip
Optional: target-KB iterative search
Optional: lossless oxipng (WASM)
Optional: AVIF (WASM)
Optional: EXIF preservation
↓
Blob ready → download or ZIP (JSZip)

Key Decisions

Web Workers, not main thread. Offloading to Workers keeps UI responsive. 4 workers in round-robin — handles 20 files
without freezing.

WASM for PNG/AVIF. Canvas does JPEG/WebP natively, but lossless PNG needs oxipng (Rust→WASM) and AVIF needs
@jsquash/avif. Both load on demand.

Zustand over Redux. For a single-page tool, Zustand wins. Entire store is ~800 lines with all compression logic.

One-time purchase, not subscription. Creem handles $24.99 lifetime Pro. No recurring billing headaches.

Numbers After 2 Weeks

744 page views, 123 unique visitors
2,847 images compressed
1 Pro sale ($24.99)
Twitter: ~5 followers

What I'd Do Differently

SEO tool pages earlier — 11 pages drive long-tail traffic
Demo showcase from day 1 — visitors need to see results first
Mobile-first testing — most users on mobile

Try It

compressfast.site (global)
jisuyatu.com (China)

This is post #4 in my CompressFast build-in-public series. Previous: [privacy-first approach], [AVIF vs WebP
benchmarks], [why your compressor uploads files].

# Why Your Image Compressor Is Uploading Your Files (And How to Stop It)

吴美良 — Mon, 27 Jul 2026 02:01:39 +0000

AVIF vs WebP vs JPEG: Real Benchmarks (2026)

吴美良 — Sun, 26 Jul 2026 03:19:48 +0000

I compressed 100 photos through 3 formats. Here's the actual data.

A 2MB JPEG photo. Convert it to WebP — now it's 480KB. Convert it to AVIF — now it's 310KB.

Same visual quality. Three different file sizes.

I've spent the last 2 weeks building an image compression tool, so I've seen thousands of these comparisons. Here's what the numbers actually say, and what it means for your website.

The Setup

I took 50 real-world photos and 50 screenshots/design assets — not synthetic test images, but actual files people would upload:

Photos: vacation shots (JPEG, 2-8MB), product photos, portrait selfies
Graphics: PNG screenshots (1-4MB), logos, UI mockups, illustrations
Source sizes: 500KB to 12MB, average ~3.2MB

Each image was compressed through JPEG (quality 85%), WebP (quality 80%), and AVIF (quality 65%) — settings that produce visually identical results on a 2x retina display.

The Numbers

Format	Avg Compressed Size	Reduction vs Original	Reduction vs JPEG	Browser Support
Original	3.2 MB	—	—	100%
JPEG (q85)	820 KB	74.4%	—	100%
WebP (q80)	480 KB	85.0%	41.5% smaller than JPEG	96.8%
AVIF (q65)	310 KB	90.3%	62.2% smaller than JPEG	93.1%

The headline: WebP halves your JPEG size. AVIF halves WebP again.

Photo Results (JPEG source, 50 images)

For photographs — the most common use case — here's what happened:

Format	Avg Size	Best Case	Worst Case
JPEG q85	820 KB	180 KB	3.1 MB
WebP q80	480 KB	95 KB	1.8 MB
AVIF q65	310 KB	60 KB	1.2 MB

What this means: On an average product page with 6 photos:

JPEG: 6 × 820KB = 4.9 MB
WebP: 6 × 480KB = 2.9 MB (saves 2 MB)
AVIF: 6 × 310KB = 1.9 MB (saves 3 MB)

On a 4G connection (10 Mbps), that's the difference between 4 seconds and 1.5 seconds to load all images. On a product page, that's the difference between a bounce and a sale.

Screenshot/Graphics Results (PNG source, 50 images)

PNGs are a different story. Lossy WebP and AVIF can crush PNGs — but only if you're OK losing pixel-perfect accuracy.

Format	Avg Size	Notes
Original PNG	1.4 MB	Lossless, pixel-perfect
PNG (lossless compress)	640 KB	Still lossless, 54% smaller
WebP q80	180 KB	Visually identical on screen, not pixel-perfect
AVIF q65	120 KB	Same visual quality as WebP

For screenshots with text, the lossless PNG compression is the safer choice — at 640KB it's still 54% smaller than the original, and every pixel is correct. For illustrations and UI mockups without fine text, WebP at q80 is visually identical and 7x smaller than the original PNG.

The Catch: Encoding Speed

There's a reason every CDN doesn't just serve AVIF by default:

Format	1 Image	30 Images (Batch)
JPEG	0.3s	9s
WebP	0.8s	24s
AVIF	2.5s	75s

AVIF is slow to encode. About 3x slower than WebP, 8x slower than JPEG. This matters if you're compressing on-the-fly (user uploads) vs at build time (static site generator).

For a static site? Use AVIF at build time, the slow encode doesn't matter.
For user-generated content? WebP is the sweet spot — fast enough, small enough.

Real-World Recommendations

For Blog / Content Site

→ WebP, quality 80%
Best balance of size, speed, and compatibility. Every modern browser supports it. Your 5MB hero image becomes 700KB. Done.

For E-Commerce / Product Pages

→ WebP for now, AVIF as <picture> fallback
Product images matter for conversion. Serve AVIF to 93% of browsers, fall back to WebP for the rest. The <picture> element handles this automatically:

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

For User-Generated Content

→ WebP, quality 80%
Users upload JPEGs. You convert to WebP. Fast encode, small output. 30 images process in ~24 seconds — acceptable for a background job.

For Screenshots / Technical Docs

→ Lossless PNG compression
Don't use lossy formats for screenshots with text. The compression artifacts around letters look unprofessional. Lossless PNG compression (oxipng, pngquant) gives you 20-60% savings without touching a single pixel.

For "I just want the smallest file"

→ AVIF, quality 60-65%
If file size is everything (email attachments, messaging apps, low-bandwidth scenarios), AVIF wins. A 4MB vacation photo becomes 250KB. Just warn users it'll take a few seconds to encode.

The Tool I Used

I built CompressFast to do these comparisons quickly — drag in images, switch formats, see before/after sizes instantly. Everything runs in the browser (no upload), so you can test with sensitive files too.

But you can also do this with:

Squoosh (squoosh.app) — great for one-at-a-time comparisons
ImageMagick (CLI) — magick input.jpg -quality 80 output.webp
sharp (Node.js) — the fastest server-side option
Cloudinary/imgix — if you want a managed solution

Bottom Line

If you're still serving JPEGs in 2026, you're leaving 40-60% of your image bytes on the table. WebP is safe, fast, and universally supported. AVIF is the next step when you're ready.

The format you pick matters less than actually picking one and compressing your images. Most sites I audit have 2-4MB hero images that could be 300KB. That's not a format problem — that's a "nobody compressed this" problem.

Start with WebP at 80%. You'll cut your image payload in half. Then worry about AVIF.

Have you switched to WebP or AVIF? What's holding you back?