DEV Community

Max
Max

Posted on • Originally published at orthogonal.info

Why I Built a Browser-Only Image Compressor (No Uploads, No Server)

Most image compression tools require you to upload your photos to a remote server. But what if you are compressing screenshots with sensitive data or client mockups under NDA?

The Privacy Problem

When you upload to a compression service, you trust that company to not store, not train AI on, and delete your image. You have no way to verify it.

For personal photos, acceptable risk. For business documents, medical images, legal screenshots? Real problem.

Client-Side Compression: How It Works

Modern browsers have powerful image processing APIs (Canvas API, OffscreenCanvas) that can resize and re-encode images entirely in JavaScript:

const canvas = document.createElement("canvas");
const ctx = canvas.getContext("2d");
canvas.width = img.naturalWidth;
canvas.height = img.naturalHeight;
ctx.drawImage(img, 0, 0);

// Export at reduced quality - never leaves the browser
canvas.toBlob(blob => {
  // blob is your compressed image
}, "image/jpeg", 0.8);
Enter fullscreen mode Exit fullscreen mode

No fetch calls, no FormData uploads, no server round-trips.

When to Use Client-Side vs Server-Side

Client-side wins when:

  • Images contain confidential information
  • You are under NDA or HIPAA compliance
  • You want fastest compression (no upload wait)
  • Slow or metered internet connection
  • You value privacy

Server-side tools may be better when:

  • You need advanced algorithms (MozJPEG, AVIF encoding)
  • Batch-processing thousands of images via API
  • You need specific format conversions

Try It

I built QuickShrink to make this dead simple. Drop an image, get a smaller one back. No signup, no uploads, no tracking.

You can verify yourself: open DevTools Network tab and watch. Zero outbound requests during compression.


What is your approach to image optimization in your projects? Do you trust upload-based tools with sensitive content?

Top comments (0)