DEV Community: swifttooly

Compressing PDFs in the browser, and the bug that shipped empty files

swifttooly — Sat, 08 Aug 2026 16:58:42 +0000

Last time I wrote about compressing images in the browser with the Canvas API. I ended that post by saying the PDF version of the story was messier. It is, and one of the bugs sat in production longer than I'd like to admit.

Same constraint as before: everything runs on the user's device. No upload, no server, no API.

A PDF has no quality slider

With an image you call canvas.toBlob(resolve, 'image/jpeg', 0.7) and you're done. There's a dial, you turn it.

A PDF is a container. Fonts, vector paths, embedded images, metadata, and a cross-reference table holding it together. No single number makes it smaller. What's making a given file heavy depends entirely on what's inside it, and two documents with the same page count can need completely different treatment.

You get roughly two options.

Rebuild the file structure. Load it with pdf-lib and write it back out:

js
import { PDFDocument } from 'pdf-lib';

const pdf = await PDFDocument.load(bytes);
const out = await pdf.save({ useObjectStreams: true });

This is lossless. Text stays selectable, fonts stay fonts. The savings are modest and sometimes zero, because all you're doing is tidying up structure.

Re-render every page. Draw each page onto a canvas with pdf.js, re-encode it as JPEG, then assemble a new PDF from those images. This is where the impressive percentages come from, and it costs you a lot: text becomes pixels, selection stops working, screen readers get nothing, and small type goes fuzzy at low quality.

Most of the online compressors advertising "up to 90% smaller" are quietly doing the second one.

The bug: pdf.js empties your buffer

This is the one that cost me real debugging time.

Here's the shape of the code that broke:

js
const buf = await file.arrayBuffer();

const doc = await pdfjsLib.getDocument({ data: buf }).promise;
const compressed = await compress(doc);

if (compressed.size >= file.size) {
// Can't beat the original, so hand it back untouched
return new Blob([buf], { type: 'application/pdf' });
}
return compressed;

Looks fine. It isn't.

getDocument({ data }) transfers the ArrayBuffer to its worker. Transferred, not copied. The moment that happens your buf is detached and its byteLength is 0. No error, no warning, just an empty buffer sitting where your file used to be.

So the fallback branch, the one that runs when a PDF is already well optimized and can't be shrunk, handed people a 0-byte download. And it only ever fired for files that couldn't be compressed, which is precisely the case I never thought to test.

The fix is one line:

js
if (compressed.size >= file.size) {
return file; // File already extends Blob
}

You never needed to reconstruct anything.

If you genuinely need the bytes after loading, copy before you hand them over:

js
const buf = await file.arrayBuffer();
const doc = await pdfjsLib.getDocument({ data: buf.slice(0) }).promise;

Two things worth knowing. getDocument also takes a plain Uint8Array, and the same detach rule applies there. And this isn't a pdf.js bug. Transferables are how you move data into a worker without copying it, and losing access on the sending side is the entire point. It's documented behaviour. I just didn't read closely enough.

Never hand back a bigger file

Same rule as the image post, and it matters more here:

js
if (out.byteLength >= file.size) return file;

PDFs produced by decent tooling are frequently well compressed already, and re-saving one can add bytes rather than remove them. A compressor that returns a larger file while reporting success is worse than one that does nothing at all.

Memory will end you

Rendering every page to canvas at full resolution kills a mobile tab. A 40-page document at 2x scale is an enormous number of pixels to hold at once, and the tab usually dies silently.

Render one page, encode it, throw the canvas away, then move to the next. Don't collect canvases in an array and process them at the end. I also cap the render scale instead of letting page dimensions decide it for me.

What I'd tell someone starting this

Try the lossless path first and measure whether it was enough. Only rasterize when the user asks for it and understands what they're trading away.

And test the path where compression fails. That's where my bug lived, and it's the branch nobody writes a test for.

The tool is at SwiftTooly if you want to try it. Free, and the file never leaves your machine.

Compressing images in the browser with the Canvas API (no server needed)

swifttooly — Sun, 12 Jul 2026 19:48:12 +0000

A while ago I wrote about why I built 50+ browser-based tools with zero backend. This time I want to go deeper into one specific tool: image compression that runs entirely in the browser. No upload, no server, no API — just the Canvas API doing all the work on the user's device.

Here's how it works, plus a couple of gotchas that cost me real debugging time.

The core idea

Image compression in the browser is surprisingly simple in principle:

Read the user's file with the File API
Draw it onto a <canvas>
Re-export the canvas as a Blob at a lower quality
Trigger a download

That's it. The user's photo never leaves their machine.

The code

async function compressImage(file, quality = 0.7) {
  // 1. Load the file into an Image element
  const img = new Image();
  img.src = URL.createObjectURL(file);
  await img.decode();

  // 2. Draw it onto a canvas
  const canvas = document.createElement('canvas');
  canvas.width = img.naturalWidth;
  canvas.height = img.naturalHeight;
  const ctx = canvas.getContext('2d');
  ctx.drawImage(img, 0, 0);

  // 3. Re-export as a compressed Blob
  const blob = await new Promise(resolve =>
    canvas.toBlob(resolve, 'image/jpeg', quality)
  );

  URL.revokeObjectURL(img.src);
  return blob;
}

Then downloading is just:

function downloadBlob(blob, filename) {
  const a = document.createElement('a');
  a.href = URL.createObjectURL(blob);
  a.download = filename;
  a.click();
  URL.revokeObjectURL(a.href);
}

Gotcha #1: transparent PNGs turn black

This one bit me in production. If the input is a PNG with transparency and you export it as JPEG, the transparent areas become solid black — JPEG has no alpha channel.

Two ways to handle it:

Option A — fill a white background first:

ctx.fillStyle = '#ffffff';
ctx.fillRect(0, 0, canvas.width, canvas.height);
ctx.drawImage(img, 0, 0);

Option B — detect transparency and export WebP instead (WebP supports alpha and compresses well):

const outputType = hasTransparency ? 'image/webp' : 'image/jpeg';
canvas.toBlob(resolve, outputType, quality);

I went with Option B — users who upload a transparent logo expect to get a transparent result back.

Gotcha #2: compression can make files BIGGER

If the input is already heavily optimized (or tiny), re-encoding it can produce a larger file. Always compare sizes and never return a worse result:

if (blob.size >= file.size) {
  return file; // keep the original
}

Sounds obvious, but a lot of online compressors skip this check and happily hand you a "compressed" file that's bigger than what you started with.

Gotcha #3: huge images can crash the tab

A 50-megapixel photo drawn onto a canvas can eat enough memory to kill the tab on mobile — silently, with no error. Add a size guard before decoding and show a friendly message instead of letting the browser die.

Why bother doing this client-side?

Privacy: the user's photos never touch a server. Nothing to store, nothing to leak.
Cost: zero bandwidth and zero server bills, no matter how many people use it.
Speed: no upload/download round-trip — compression starts instantly.

The limits are real too: no server means no ML-based smart compression, and very large batches are constrained by device memory. For everyday "shrink this photo before emailing it" use cases, though, the browser is more than enough.

Try it live

I use exactly this approach (plus resize-before-compress for extra savings) in the Image Compressor on SwiftTooly — free, no sign-up, and your files stay on your device.

Questions about the implementation? Happy to share more details in the comments — the PDF compression story is even messier, and I might write that one up next.

Why I built 50+ browser-based tools with zero backend

swifttooly — Sun, 28 Jun 2026 20:35:00 +0000

For years, every time I needed to merge a PDF or compress an image online, I had to upload my private files to some random server and just hope they got deleted. That always felt wrong.

So I started building small tools that do everything in the browser — no upload, no backend, no database. The files never leave the user's device. I ended up with 50+ of them, and I want to share what I learned about going fully client-side.

Why client-side?

Three big wins:

Privacy: the user's files never touch a server. Nothing to leak, nothing to store, nothing to comply with.
Cost: no server means no hosting bill that scales with traffic. A static site can handle millions of users.
Speed: no upload/download round-trip. The work happens instantly on the user's machine.

The browser can do more than people think

Most "simple" tools don't actually need a server. Modern browser APIs cover a huge amount:

Canvas API — resize, crop, compress, and convert images entirely in memory.
File API + Blob — read user files and trigger downloads without ever uploading.
Web Crypto API — hashing (SHA-256, etc.) natively, no library needed.
Libraries like pdf-lib and pdf.js — full PDF manipulation (merge, split, rotate) on the client.

For example, compressing an image is just: read the file → draw it to a canvas → re-export at a lower quality → download the blob. No server in the loop.

What does NOT work client-side

Being honest about the limits, because this matters:

Downloading videos from YouTube/TikTok — blocked by CORS, needs a server.
Anything needing live data (real-time currency rates, etc.) — needs an API.
Heavy video transcoding — technically possible with WASM but painful and slow.

Knowing what can't be done client-side saved me from shipping broken tools.

The result

I put all of this into [SwiftTooly] — a free collection of browser-based tools (PDF, image, text, QR, converters, dev utilities). Everything runs locally, no sign-up.

Happy to answer questions about any of the implementations — the image and PDF stuff especially has some fun edge cases.

What other tools do you think genuinely don't need a backend?