DEV Community: Gaurav Bhowmick

I replaced server-side image compression with 40 lines of Canvas API code

Gaurav Bhowmick — Tue, 05 May 2026 01:15:25 +0000

I was building a side project that needed image compression. My first instinct was to look for an API — TinyPNG, Cloudinary, something with a POST endpoint.
Then I looked at the pricing. And the rate limits. And the fact that I’d be uploading user photos to someone else’s infrastructure.
So I tried something different: what if the browser just… did it?
Turns out the Canvas API can compress images surprisingly well. The core logic is about 40 lines:
const fallbacks = [0.6, 0.45, 0.3, 0.2];
let blob = await compress(img, quality, format);

if (blob.size >= file.size) {
for (const fq of fallbacks) {
const attempt = await compress(img, fq, format);
if (attempt.size < file.size) {
blob = attempt;
break;
}
}
}

Try the requested quality first. If the output is bigger, walk down through lower qualities until something sticks. As a last resort, if WebP output is still larger, fall back to JPEG entirely.
Not elegant, but it works on basically everything I’ve thrown at it.
A side effect I didn’t expect
The Canvas API strips all EXIF metadata. When you draw an image to canvas and export it, the output contains zero metadata — no GPS coordinates, no device model, no timestamps.
I originally considered this a bug. Then I realized most people compressing passport photos and ID scans probably want that metadata gone. So I kept it as a feature.
What about PDFs?
I needed PDF-to-image conversion for a separate use case and figured I’d add it to the same tool. pdfjs-dist handles the rendering, jsPDF handles the reverse direction. Both run client-side.
The tricky part was pdfjs-dist v5 breaking everything. Downgraded to v3.11.174 and it worked immediately. Also had to add canvas: false to the webpack config because pdfjs tries to import the Node canvas module during build.
The result
I bundled all of this into a tool called MiniPx (minipx.com). The whole thing is a static Next.js export on Netlify. No backend. Server cost is literally zero.
Features that exist because I kept needing them:
• Multi-pass compression with format fallback
• WebP/JPEG/PNG conversion
• Resize with presets (passport, email, WhatsApp)
• EXIF stripping (automatic)
• PDF to image and image to PDF
• Batch ZIP download via jszip
The entire homepage is one React component at ~400 lines. Heavy libraries (pdfjs, jspdf, jszip) are lazy-loaded so they don’t affect initial page load.
Not saying this replaces server-side compression for production pipelines. But for a utility tool where users compress a few photos? The browser handles it fine.
Source of the compression approach is just the standard Canvas API — no special libraries needed for the image part. The interesting engineering was mostly in the fallback logic and making sure memory gets cleaned up (revokeObjectURL after every operation, reset canvas dimensions after PDF rendering).
If you’re building something similar, the main gotchas:
1. Always check if output > input. Canvas compression can make files larger.
2. JPEG needs a white background fill before drawImage, or transparent areas turn black.
3. Mobile browsers have canvas size limits. Cap your render scale.
4. pdfjs-dist v5 is broken for client-side use. Stick with v3.
Happy to answer questions if anyone’s doing something similar.

I built an image compressor that never sees your images published

Gaurav Bhowmick — Sat, 02 May 2026 07:23:48 +0000

Every online image compressor I tried had the same problem: they upload your photos to a server.
TinyPNG, iLoveIMG, Compress2Go — they all work the same way. You pick a file, it goes to someone else's computer, gets compressed, comes back. The compression is good. But your photo — with its GPS coordinates, device serial number, and timestamps baked into the EXIF data — just sat on a server you don't control.
I kept thinking: image compression is just math. It's Canvas API, quality parameters, and blob manipulation. There's no reason this needs a server.
So I built MiniPx. It compresses, converts, and resizes images entirely in the browser. Nothing gets uploaded. Ever. Here's how it works under the hood.
The core compression loop
The actual compression happens in about 20 lines. Load the image into a canvas, draw it, export as a blob with a quality parameter:

javascriptfunction compressAtQuality(img, w, h, fmt, quality) {
return new Promise((resolve, reject) => {
const canvas = document.createElement('canvas');
canvas.width = w;
canvas.height = h;
const ctx = canvas.getContext('2d');

// White background for JPEG (no transparency support)
if (fmt === 'image/jpeg') {
  ctx.fillStyle = '#fff';
  ctx.fillRect(0, 0, w, h);
}

ctx.drawImage(img, 0, 0, w, h);
canvas.toBlob(
  (blob) => blob ? resolve(blob) : reject(new Error('No output')),
  fmt,
  fmt === 'image/png' ? undefined : quality
);

});
}

That's it. No sharp, no imagemagick, no server-side anything. The browser's built-in JPEG/WebP encoder handles the actual compression.
The problem nobody talks about: when compression makes files bigger
Here's something I didn't expect. If you take a well-optimized JPEG and run it through Canvas at quality 0.65, the output can be larger than the input. The browser re-encodes the entire image from scratch — it doesn't know the original was already compressed.
I hit this constantly during testing. Users would drop a 200KB JPEG and get back a 280KB file. That's embarrassing.
The fix is a fallback chain. If the initial compression produces a bigger file, step down through lower quality levels until you beat the original:

javascriptlet blob = await compressAtQuality(img, w, h, fmt, quality);

if (blob.size >= file.size && fmt !== 'image/png') {
for (const fallbackQ of [0.6, 0.45, 0.3, 0.2]) {
if (fallbackQ >= quality) continue;
const attempt = await compressAtQuality(img, w, h, fmt, fallbackQ);
if (attempt.size < file.size) {
blob = attempt;
break;
}
if (attempt.size < blob.size) blob = attempt;
}

// Last resort: try a different format entirely
if (blob.size >= file.size && fmt === 'image/webp') {
const jpegFallback = await compressAtQuality(
img, w, h, 'image/jpeg', Math.min(quality, 0.5)
);
if (jpegFallback.size < blob.size) blob = jpegFallback;
}
}

Not elegant, but it works. The user always gets a smaller file, even if the format or quality level isn't what they originally picked.
PNG is a special headache
PNG compression through Canvas is basically useless. The browser's PNG encoder produces files that are often 1.5-2x larger than the input because it doesn't do the advanced filtering and dictionary optimization that tools like pngquant use.
My workaround: if a PNG output is significantly larger than the input, quietly try WebP and JPEG alternatives and pick the smallest:

javascriptif (blob.size > file.size * 1.5 && fmt === 'image/png') {
const webpAlt = await compressAtQuality(img, w, h, 'image/webp', quality);
const jpegAlt = await compressAtQuality(img, w, h, 'image/jpeg', quality);
const smallest = [blob, webpAlt, jpegAlt].sort((a, b) => a.size - b.size)[0];
if (smallest.size < blob.size) blob = smallest;
}

This means a user who drops a 4MB PNG screenshot might get back a 400KB WebP instead of the 6MB PNG that Canvas would produce. The file extension changes, which is a tradeoff, but a 93% size reduction beats format purity.
HEIC conversion without a server
This was the trickiest part. iPhones save photos as HEIC by default. Most online converters upload them to a server for decoding because browsers don't natively support HEIC — except Safari does.
So MiniPx checks first:
javascriptconst supportsHEICNatively = async () => {
return new Promise((resolve) => {
const img = new Image();
img.onload = () => resolve(true);
img.onerror = () => resolve(false);
img.src = 'data:image/heic;base64,AAAAGGZ0eXBoZWlj';
setTimeout(() => resolve(false), 500);
});
};

Safari users get zero-dependency HEIC conversion through the same Canvas trick — load the HEIC into an , draw to canvas, export as JPEG. No libraries needed.
Chrome and Firefox users get heic2any, which is a WASM-based HEIC decoder. It's about 350KB, which is heavy, so I lazy-load it only when someone actually tries to convert a HEIC file:
javascriptconst heic2any = (await import('heic2any')).default;
return await heic2any({ blob: file, toType: 'image/jpeg', quality: 0.92 });
Safari users never download those 350KB. Chrome users only download them if they actually need HEIC conversion. Everyone else gets the lightweight path.
Stripping EXIF data (the privacy part)
This is maybe the most important feature and it's almost invisible. Photos from phones contain EXIF metadata: GPS coordinates, device model, serial numbers, timestamps, sometimes even your name.
When you re-draw an image through Canvas, the EXIF data doesn't come along. Canvas only sees pixels — it has no concept of metadata. So every image that passes through MiniPx comes out clean. No GPS. No device info. No timestamps.
I added a toggle for this ("Strip EXIF data") but it's on by default. The Canvas re-encoding handles it automatically — there's no extra code needed.
The architecture
MiniPx is a Next.js 15 static site. No API routes. No database. No server functions. The entire thing is pre-rendered HTML + JS served from Netlify's CDN.
Stack:

Next.js 15 (static export)
5 client components: ImageTool, PDFTool, HEICTool, TrackedCTA, WebVitals
Everything else is server-rendered (SEO content, schemas, navigation)
8 dependencies total
Hosted on Netlify (free tier) The First Load JS for any page is about 103-106KB. That's the entire app — React, the compressor, the UI, everything. For comparison, TinyPNG's homepage loads 2.4MB of JavaScript. I'm pretty aggressive about keeping things server-rendered. The tool pages have long-form SEO content, FAQ accordions, and JSON-LD schemas, but all of that renders on the server as static HTML. The only client-side JavaScript is the actual image processing tool. What I'd do differently Batch processing is slow. Right now, files are processed sequentially. Web Workers would let me compress multiple images in parallel, but Canvas API doesn't work in Workers. OffscreenCanvas exists but browser support is spotty. I'm keeping an eye on this. The PNG problem is unsolved. Client-side PNG optimization is genuinely hard. There are WASM ports of pngquant and oxipng, but they add 500KB+ to the bundle. For now, the format-switching fallback works, but it's a hack. No preview. You can't see the compressed image before downloading it. Adding side-by-side preview would be a better UX, but it means holding two blob URLs in memory per image, which gets expensive with batch uploads. Try it

*MiniPx is free. No signup, no limits, no ads. *

If you're building something similar, the key insight is: Canvas + toBlob gives you 90% of what server-side image processing does, with zero infrastructure cost. The other 10% (PNG optimization, HEIC on non-Safari, advanced filters) requires WASM libraries, but you can lazy-load those so most users never pay the cost.

I built a free image compressor that never uploads your files

Gaurav Bhowmick — Sun, 19 Apr 2026 18:13:12 +0000

Every free image compressor I tried had the same problems: they upload your images to some server, limit you to 5 files a day, or force you to create an account.
I just wanted to drop images, compress, download. So I built one.
Meet MiniPx
minipx.com — a free image compressor that runs 100% in your browser. Your images never leave your device.
How it works
The compression engine uses the HTML5 Canvas API. Here's the core idea:

Load the image into a Canvas element
Re-encode it at a lower quality using canvas.toBlob()
If the output is larger than the original (happens with PNGs), try progressively lower quality settings
If WebP still can't beat the original, fall back to JPEG
Always return the smallest successful result

Code:
// Simplified version of the multi-pass compression
async function compress(file, quality, format) {
const img = await loadImage(file);
const canvas = document.createElement('canvas');
canvas.width = img.naturalWidth;
canvas.height = img.naturalHeight;
const ctx = canvas.getContext('2d');
ctx.drawImage(img, 0, 0);

// First pass
let blob = await canvasToBlob(canvas, format, quality);

// Smart fallback if output is larger
if (blob.size >= file.size) {
for (const q of [0.6, 0.45, 0.3, 0.2]) {
const attempt = await canvasToBlob(canvas, format, q);
if (attempt.size < file.size) {
blob = attempt;
break;
}
}
}
return blob;
}

The key insight: Canvas API quality values aren't linear. Quality 0.92 barely compresses anything. Quality 0.65 (our "Smart" preset) gives 50-70% reduction with no visible quality loss.
Features

Compress — Gentle (20-40%), Smart (50-70%), Tiny (75-90%)
Convert — WebP, JPEG, PNG in any direction
Resize — Set max width to 1920, 1280, or 800px
Batch — No file limits, process as many as you want
Private — Zero server uploads, works offline

Tech stack

Next.js 15 (static export)
React 19
Canvas API for compression
Deployed on Netlify (zero server cost)

What I learned
Canvas API quality is not what you think. I initially set the "Smart" preset to quality 0.78 thinking that's decent compression. A 3MB PNG screenshot compressed to 3.2MB — larger than the original. Turns out 0.78 is barely any compression for the Canvas encoder. Dropping to 0.65 fixed everything.
The multi-pass approach matters. A single-pass compressor will sometimes produce files larger than the original, especially with PNG screenshots. The fallback chain (try lower quality → try different format) ensures the output is always smaller.
Static sites are underrated for tools. MiniPx costs $0/month to run. No server, no database, no file storage, no bandwidth costs. The entire thing is HTML/CSS/JS served from a CDN.
Try it
minipx.com — would love your feedback. What features would you want added?