Encode at a quality and read the size

canvas.toBlob(callback, "image/jpeg", quality) gives you a Blob. blob.size is the file size in bytes. That is all you need to measure.

function encode(bitmap, width, height, quality) {
  const canvas = document.createElement("canvas")
  canvas.width = width
  canvas.height = height
  const ctx = canvas.getContext("2d")
  ctx.fillStyle = "#fff" // JPEG has no alpha; transparent PNGs turn black without this
  ctx.fillRect(0, 0, width, height)
  ctx.imageSmoothingQuality = "high"
  ctx.drawImage(bitmap, 0, 0, width, height)
  return new Promise((resolve) => canvas.toBlob(resolve, "image/jpeg", quality))
}

Load the bitmap with createImageBitmap(file, { imageOrientation: "from-image" }), otherwise phone photos come out sideways because the EXIF rotation is ignored.

Binary search on quality

File size grows with quality, so you can search for the highest quality that still fits:

let low = 0.3, high = 0.95, best = null
for (let i = 0; i < 6; i++) {
  const q = (low + high) / 2
  const blob = await encode(bitmap, w, h, q)
  if (blob.size <= targetBytes) { best = blob; low = q } else { high = q }
}

Six rounds narrows the range to about 1% of quality, which is more precision than the file size needs. Count 1 KB as 1000 bytes, not 1024, so the file passes whether the form counts KB one way or the other.

Know when to stop

Here is the part the sliders do not tell you. Below roughly 30% JPEG quality a photo breaks into visible blocks and the colours shift. A file that is technically under the limit but looks like that gets rejected by a human reviewer or looks bad on an ID. So the search never goes below 0.3. First it encodes once at 0.3 for the current size. If that is still over the limit, it makes the picture smaller instead: width and height times 0.8, and try again. It tries up to 12 sizes, which is down to about a tenth of the original width. Only at the last size does it allow quality all the way down to 0.05, because a file that fits beats no file.

PNG has no quality setting, so for PNG only the dimensions change.

What I would do differently

• Offer a "keep exact width and height" switch for forms that demand fixed pixels, and then accept a lower quality or a missed target. The tool I built has one, and it tells the user when the target was missed.
• Test the search with a fake encoder. The function takes the encoder as a parameter, so unit tests can pass a function that returns a Blob of a size you choose, with no canvas involved.

The tool built on this, with nothing uploaded anywhere:

• Image compressor with a target size: https://www.toolsy-hub.com/tools/image-compressor
• Photo resizer for exact KB and pixel presets: https://www.toolsy-hub.com/tools/photo-signature-resizer

Google Analytics counts visits on the site; image files are never sent anywhere.

The three engines

• pdf-lib (1.17) reads and writes the PDF structure: merging, splitting, picking pages, building a PDF from JPGs. It is plain JavaScript and works the same in every modern browser.
• pdf.js (Mozilla's renderer) draws a page onto a canvas. I use it to turn pages into images for "PDF to JPG" and for the stronger compress mode.
• qpdf, compiled to WebAssembly (about 1.3 MB), removes the password and restrictions from a PDF when the user types the password they already know. pdf-lib cannot decrypt, so this is the one job that needed a native tool.

None of them load with the page. Each is imported inside the click handler with await import(...), so someone who only wants the word counter never downloads a PDF engine.

Caching the engines for a year

The WASM and worker files are copied at build time into a folder named after the package version, for example /engines/qpdf-<version>/, and served with Cache-Control: public, max-age=31536000, immutable. A new version gets a new folder, so a browser never mixes an old worker with new code, and a returning visitor does not download 1-2 MB again.

Compress: two modes, and why

There is no magic "compress PDF" call. What shrinks a PDF depends on what is inside it.

1. Light mode re-saves the file with pdf-lib using compressed object streams. Text stays selectable. The saving is small, often a few percent, because the pictures inside are untouched.
2. Image mode renders every page with pdf.js to a JPEG (150 dpi at quality 0.8 for "high", down to 96 dpi at 0.5 for "low") and builds a new PDF from those images. For scanned documents, which are pictures anyway, this is where the big savings are. The cost: text becomes part of the picture and is no longer selectable.

The tool says which mode does what before you click, rather than after.

Hitting an exact size

Upload forms in Pakistan ask for "PDF under 200 KB" or "under 100 KB", so a slider is not enough. With a target set, the pages are rendered at the sharpest level first, and the packer lowers JPEG quality only as far as it has to until the whole PDF fits. If it cannot get there, it says so instead of quietly handing back a file that is still too big.

What does not work well

• Very large files on phones. Rendering 60 pages at 150 dpi in a phone browser uses a lot of memory. Server tools win here.
• Image mode on text PDFs. A text-only PDF can come out bigger as images. Light mode is the right choice there. Image mode is still the default, because most files people bring to a "PDF under 200 KB" form are scans.
• Password cracking. The unlock tool opens a file with the password you type. It does not guess passwords, on purpose.

Try it

The tools are free with no sign-up: Compress PDF, Merge PDF, Unlock PDF. Open the network tab while you use one and you will see no request carrying your file.

If you have built something similar, I would like to hear how you dealt with memory on phones.