Processing PDFs entirely in the browser: what building 168 client-side tools taught me

PdfPixel Tech — Fri, 06 Nov 2026 02:42:52 +0000

Every PDF website you have used asks the same quiet favour: upload your file to our server.
For a menu PDF that is fine. For a bank statement, a medical report or a signed contract,
"trust us" is a much bigger ask. A few years ago the honest alternative did not exist.
Today it does, and building PdfPixel — 168 PDF and image tools that
never upload anything — taught me exactly where the browser is strong, and where it still bites.

The architecture in one paragraph

PdfPixel is a single-origin app. There is no upload endpoint because there is no backend to
upload to. Each tool lazy-loads its own engine: pdf-lib for writing
and merging, PDF.js for parsing and rendering, Tesseract's WASM build for OCR, and an ONNX
model for subject cut-out in the background remover. Cloudflare Functions sit in front only to
serve per-route static <head> tags, hreflang blocks and JSON-LD; the bytes of your document
never leave the device.

That constraint shaped everything else. If the phone has 4 GB of RAM and a WASM heap ceiling,
you cannot decompress a 400-page scan into bitmaps all at once. So compression works in page
chunks, OCR streams tile by tile, and the background remover downloads its model once and
caches it for later runs.

Three problems worth your evening

HEIC is a licensing ghost. iPhone photos arrive as HEIC, and browsers outside the Apple
ecosystem cannot decode it natively. The fix is a WASM build of libheif, but the real lesson is
product-shaped: detect early, tell the user in plain words, and convert once, deliberately,
instead of re-encoding through three pipelines.

EXIF orientation lies to you. A photo "rotated wrong" is usually a JPEG whose orientation
flag was ignored by one pipeline and honoured by another. Read the flag, apply it once at
decode time, then strip metadata on export. Users experience this as "the tool fixed my
photo", and really it is the tool refusing to be confused.

OCR errors cluster, they do not scatter. Zero for O, one for lowercase L, rn becoming
m, and in Devanagari, matras shifting silently so a word changes meaning. Knowing the
cluster lets you design the proofread pass: numbers get read aloud, Hindi gets word-level
attention, everything else gets a glance.

Privacy as a feature, not a banner

"No uploads" sounds like marketing until you watch where the bytes go. DevTools network tab,
file open, tool run, export: zero document requests. Analytics and ads are consent-gated and
load only after an explicit allow. The privacy promise became an architecture review instead
of a policy page, and that is the only kind users can verify.

What I would tell myself at tool #1

Ship the boring tools first. Merge, split, compress and JPG-to-PDF carry most real usage; the
exotic ones (favicon from PNG, pixel-art converter) are joy and long-tail SEO, not the core.
Write the guide next to the tool: "compress under 100 KB for SSC forms" answers a question
people actually type, and the tool is the answer's last paragraph.

If you want to poke at the behaviour, the whole suite is at
pdfpixel.tech — open DevTools, watch the network tab stay quiet, and
break something interesting. Questions and war stories welcome in the comments.

DEV Community: PdfPixel Tech

Processing PDFs entirely in the browser: what building 168 client-side tools taught me

The architecture in one paragraph

Three problems worth your evening

Privacy as a feature, not a banner

What I would tell myself at tool #1