DEV Community: Edem DOGBE

Shrinking a PDF Without Turning Its Pages Into Pictures

Edem DOGBE — Sun, 01 Nov 2026 08:38:17 +0000

Most browser-side "compress PDF" code does the same thing. It renders every page to a canvas, encodes that canvas as a JPEG, and builds a new PDF with one picture per page. It works on anything, and the file usually gets smaller. It also destroys the document: the text can no longer be selected or searched, vector drawings become blurry pixels, links are gone, and a screen reader finds nothing to read.

For a scanned contract that is a fair trade. For a report that is heavy only because someone pasted ten phone photos into it, it is the wrong tool. The text and vector graphics weigh almost nothing; the photos are the only thing worth touching.

This post walks through the second approach as we implemented it in the PDF compressor of VellumPDF, which runs entirely in the browser with pdf-lib and a canvas. Most of the work is not compressing. It is deciding which images you are allowed to compress.

Images in a PDF are just streams

An image in a PDF is an object, usually shared: a stream whose dictionary says /Subtype /Image, with its width, height, color space, bits per component and the filter that encodes its bytes. Pages do not contain the image; they reference it by object number. The same logo can appear on every page and exist once in the file.

That gives you a clean plan:

Walk every indirect object in the document.
Keep the raw streams whose dictionary says /Subtype /Image.
Decode the pixels, resize them if they are larger than needed, re-encode them as JPEG.
Put the new bytes back under the same object number, so every page that pointed to the old image now points to the new one without being touched.

With pdf-lib, step 1 is doc.context.enumerateIndirectObjects(), which returns [ref, object] pairs. Step 4 is less obvious. pdf-lib's JpegEmbedder has an embedIntoContext(context, ref) method, and if you pass it an existing ref, it writes the new image stream into that slot instead of allocating a new one:

const embedder = await JpegEmbedder.for(newJpegBytes)
await embedder.embedIntoContext(doc.context, ref)

The embedder builds a fresh dictionary for the stream (width, height, color space read from the JPEG itself, /DCTDecode). Anything the old dictionary carried is lost, which matters for transparency, as we will see.

The eligibility list is the real work

If you recompress every image you find, some documents will come out with wrong colors, broken transparency or invalid structure. Our eligibility function returns "leave it alone" for all of the following. Each rule exists because of a specific way to break a file.

Stencil masks (/ImageMask true). These are 1-bit shapes painted with the current fill color, not pictures. Turning one into a JPEG makes no sense.

An explicit /Decode array. It remaps sample values, sometimes inverting them. Re-encoding the decoded pixels and dropping the array would flip or shift the image.

A /Mask entry. Either a color-key mask (an array: "treat these colors as transparent") or a stencil stream. JPEG is lossy and shifts colors slightly, so a color key that matched exact values stops matching. And since the new dictionary is built from scratch, the entry would be lost anyway.

A soft mask carrying /Matte. A soft mask (/SMask) is a grayscale stream that gives an image its alpha channel. When it has a /Matte entry, the image was pre-blended with a background color, and the specification requires the mask and the image to have the same dimensions. Shrink the image and the file is no longer valid. So these are skipped too.

Any filter other than DCTDecode or FlateDecode. JBIG2 and CCITT are bilevel formats that already compress black-and-white scans far better than JPEG ever will. JPX (JPEG 2000) and LZW are rare enough that we left them out rather than ship a decoder for them.

Anything other than 8 bits per component, for Flate images.

Flate images with a PNG or TIFF predictor. With /DecodeParms << /Predictor 10..15 >>, the inflated bytes are not pixels yet; each row starts with a filter byte and stores differences from the row above. You have to undo that before you have an image. We do not, so these images stay as they are. This is a real gap: images that came from PNG files often use predictors.

Color spaces other than gray or RGB. We accept DeviceGray, DeviceRGB, and ICCBased with 1 or 3 components. Everything else is skipped: CMYK, Indexed, Separation, DeviceN, CalRGB. CMYK JPEGs deserve a special mention. Files written by Adobe software often store them inverted and flag it in an APP14 marker. Decode one in a browser, re-encode it, and you get an RGB image with colors that range from slightly off to photographic negative. Not worth the risk.

One more rule sits outside the per-image check. Before the main loop, we collect every object that some other image references as its /SMask. Those streams look exactly like ordinary 8-bit grayscale images, and the main loop would happily recompress them. A soft mask turned into a lossy JPEG gets fuzzy edges and halos, so mask streams are never touched.

Decoding, resizing, encoding

Once an image passes, the pixels come from one of two paths.

For a DCTDecode stream, the bytes are a JPEG file. The browser decodes it: createImageBitmap(new Blob([bytes], { type: 'image/jpeg' })), draw it on a canvas, read back getImageData.

For a FlateDecode stream, pdf-lib inflates it with decodePDFRawStream(stream).decode(), and we expand the gray or RGB samples to RGBA ourselves. If the inflated buffer is shorter than width × height × components, the stream is truncated or we misread it, and we bail out on that image.

Then: optional grayscale conversion, a resize so that the longest side does not exceed a limit, and canvas.toBlob(callback, 'image/jpeg', quality). Our default setting caps the longest side at 2000 pixels and uses quality 0.75.

The step that matters most comes next:

if (newJpeg.length >= original.length) continue // keep the original

An image that is already a well-compressed JPEG, or a small flat-color Flate image, can come out larger after re-encoding. We only swap when the result is lighter. Without this check, "compression" makes some files grow.

If the original image had a soft mask, we put the reference back on the new dictionary after embedding:

const smask = dict.get(PDFName.of('SMask'))
await embedder.embedIntoContext(context, ref)
if (smask) context.lookup(ref, PDFStream).dict.set(PDFName.of('SMask'), smask)

A decode or encode failure on a single image (a damaged progressive JPEG, for instance) is caught and skipped. One bad image should not fail the whole document.

Finally the document is saved with doc.save({ useObjectStreams: true }), which packs the small non-stream objects into compressed object streams. On its own, that re-save is our lossless "Light" level, which can save a little on files written by tools that did not use object streams.

The grayscale trap

Our "grayscale images" option has a limit worth knowing. The canvas JPEG encoder only writes three-component JPEGs. Set R = G = B on every pixel and the image looks gray, but the file keeps three channels, and pdf-lib tags it DeviceRGB. You lose the color without saving the bytes a one-channel JPEG would save. Real single-channel output means shipping your own JPEG encoder.

Hitting a target size without compounding damage

People rarely want "compress at level 2". They want "under 2 MB, because the upload form says so". Our target-size mode tries settings in order: first image recompression with progressively stricter limits (2000 px at 0.75, then 1600 px at 0.6, 1200 px at 0.45, 900 px at 0.3), and only after that, as a last resort, full-page rasterization at decreasing scales.

Two details made this behave well.

Every attempt starts from the original bytes. It is tempting to feed attempt N's output into attempt N+1. That re-encodes JPEGs that were already re-encoded, and each pass adds artifacts on top of the previous ones. Reloading the original is slower and gives a cleaner result at the same size.

The best result is kept even if the target is missed, and the user is told. The interface says plainly whether the target was reached, and shows a separate warning when reaching it required converting pages to images, because at that point the text is no longer selectable. If the output is heavier than the input, a "Keep the original" button appears. Silently delivering a worse file is the failure mode to avoid.

Keeping the PDF logic testable

The module that walks the PDF never imports a canvas. The JPEG decoder and encoder are passed in as functions. In the browser they wrap createImageBitmap and canvas.toBlob. In a Node test they wrap @napi-rs/canvas. Everything else (object traversal, eligibility, stream replacement, the size comparison) is plain JavaScript that runs under Node against real PDF files, without a browser.

That split matters because the eligibility rules are where the bugs hide, and the cases worth checking (a CMYK JPEG, a masked image, a predictor-encoded Flate stream) are much easier to feed to a Node script than to click through in a browser.

Try it on a real file

If you want to see the behavior on your own files, the compressor runs locally in the tab, next to the other free PDF tools on VellumPDF. Try a document with selectable text on the default level, then on "Maximum", and compare what you can still copy out of each.

Does That Online PDF Tool Upload Your File? A Network Test You Can Run Yourself

Edem DOGBE — Thu, 01 Oct 2026 11:43:03 +0000

Most online PDF tools tell you the same thing: your files are deleted after an hour. That sentence answers a question nobody asked. A server can only delete a file it has received, so the real question is whether the file left your machine at all, and when.

You don't need to trust anyone's answer to that. The browser already records every request a page makes. With the developer tools open and a test file, you can see an upload happen, measure it, and find out which server received it. Here is the method we used for a network measurement of popular PDF tools, written so you can repeat it on any site.

Prepare a file you can afford to leak

Never test with a real document. Generate a PDF with obviously fake content ("TEST DOCUMENT", a made-up client, a made-up amount) and note its exact size in bytes. Ours was eight pages. The size matters more than the content: you'll recognise the upload because a request body roughly that large shows up in the log.

Set up the Network panel

In Chrome or Edge, open DevTools (F12) and go to the Network tab. Three settings change what you see:

Preserve log. Without it, the log is wiped when the page navigates, and some tools redirect to a result page right after upload.
Disable cache. Optional, but it makes the page download its code for real, so you can tell code loading apart from everything else.
Clear the log just before you drop the file. Everything that appears afterwards happened because of your file.

Firefox has the same thing: Network Monitor, with "Persist Logs" in the settings menu.

Now drop the test file into the tool and watch. Don't click anything else yet.

What an upload looks like

An upload is a request that carries a body. In practice that means a POST or PUT, usually multipart/form-data, and a request body about the size of your file.

Type method:POST in the filter box to hide everything else. For each remaining request, open it and check two places:

the Headers tab, under Request Headers: Content-Length and Content-Type;
the Payload tab, which shows the form fields being sent, usually including the file name.

Careful with the Size column in the main table. It shows what came back, not what went out. A 2 MB upload that gets a short JSON reply shows a few hundred bytes there. Request size is only visible inside the request.

Then look at the timing. On 29 August 2026 we ran this test on the compression tool of four popular services. Three of them (iLovePDF, PDF2Go and PDF24 Tools) sent the file as soon as it was dropped, before any "Compress" button was clicked. One of them also fired a request to Microsoft Clarity, a session-analytics service, during the operation. For the fourth, Smallpdf, our automated harness couldn't trigger the native file picker, so we recorded it as not measured instead of guessing. Infrastructure changes, so these results hold for that date only.

None of this is hidden or illegal. It is how a server-side tool works: the server is the engine, so the file has to travel. The test simply lets you see it instead of inferring it from a privacy page.

Find out where it went

The request URL gives you a hostname, such as api110.ilovepdf.com. Two commands turn that into a location:

dig +short api110.ilovepdf.com
whois 57.129.84.252 | grep -iE 'org-name|orgname|country|netname'

The first resolves the host to an IP address, the second asks the regional registry who holds that address block. In our run the uploads ended up with OVH and Hetzner, both in Germany. Two caveats: a CDN or load balancer in front of the real server will show the CDN's address, and the IP you get can depend on where you resolve from. Write down the date and your location next to the result.

What is not an upload

A page that processes files locally still makes requests. Learning to read them is what keeps this test honest.

Code downloads. A browser-only tool has to fetch its engine before it can run. In VellumPDF, pdf-lib is loaded with a dynamic import() the first time it's needed rather than on page load, and heavier engines, such as qpdf compiled to WebAssembly, arrive the same way when a tool calls for them. With Disable cache on, you'll see .js and .wasm files arrive after the drop. They are GET requests with no request body. Data comes in; nothing about your file goes out.

Analytics. Most sites send page views somewhere. Check what the body contains. Our own site, once a tool has been used, sends one usage event carrying the tool's identifier and nothing else: no file name, size or content. It deliberately sends it when you leave the page, not during processing. A strict test should still show it to you: navigate away with Preserve log on and you'll see it.

Model downloads. Some local features need large data files, such as OCR language models. Those are downloads too, and a well-behaved page tells you before it fetches them.

The rule: anything with a request body during processing deserves a look. Anything without one is the page receiving, not sending.

Read the page's own rules

One response header tells you which servers a page is allowed to contact at all. Open the main document request and find Content-Security-Policy, then the connect-src directive. Ours reads:

connect-src 'self' https://huggingface.co https://*.huggingface.co https://*.hf.co https://raw.githubusercontent.com

That means scripts on the page can only fetch its own origin and the hosts that serve models. It's a strong hint, not proof: a CSP doesn't stop a page from uploading to its own origin, and a site can change its header tomorrow. Combine it with the network log.

Blind spots of the method

The Network panel is good, not perfect. Know where it can miss things:

Chunked uploads. A large file may be split into many requests. Add up the request bodies instead of looking for one large one.
Deferred sends. A page can queue data and send it with navigator.sendBeacon or fetch(..., { keepalive: true }) when you close the tab. Keep Preserve log on and navigate away before you conclude anything.
WebSockets. Frames are under the request's Messages tab, not in the request list.
WebRTC. Data channels don't appear in the Network panel at all. Chrome shows them in chrome://webrtc-internals.
Native file pickers and extensions. Automated harnesses struggle with some upload widgets, which is why one service in our table is marked not measured. A manual run with DevTools open avoids that.

The offline check, and its limit

A quicker test: load the tool, process a file once, then turn off your network and process another. If it works offline, that operation doesn't need a server. That's a clean positive result.

A failure proves less. The tool might simply not have downloaded its engine yet, because lazy-loaded code can't arrive without a connection. Run the operation once online first so the code is loaded, then cut the connection.

Measuring from inside the page

We wanted users to get this information without opening DevTools, so the result panel of our compress tool, shared by the other tools, reports how many bytes the page sent since the file was dropped. The Performance API won't tell you that: PerformanceResourceTiming has transferSize and encodedBodySize, but both describe the response. Request bodies are invisible to it.

So the page wraps the sending functions before anything else runs and measures each body as it goes out:

const sent = []
const originalFetch = window.fetch.bind(window)

window.fetch = (input, init) => {
  const url = typeof input === 'string' ? input : input.url
  sent.push({ t: performance.now(), url, bytes: bodySize(init?.body) })
  return originalFetch(input, init)
}

function bodySize(body) {
  if (body == null) return 0
  if (typeof body === 'string') return new TextEncoder().encode(body).byteLength
  if (body instanceof Blob) return body.size
  if (body instanceof ArrayBuffer || ArrayBuffer.isView(body)) return body.byteLength
  return 1 // a stream: size unknown, never report zero
}

The real version also wraps XMLHttpRequest.prototype.send and navigator.sendBeacon, handles FormData and Request objects, and uses the resource timeline to count loads from other origins.

It has limits we state on the privacy page. Requests made inside a Web Worker go through the worker's own fetch, so the window's wrapper never sees them. In our case those are engine downloads from our own domain, which DevTools does show. The bigger limit is a matter of principle: a page reporting on itself is a self-report. Code that wanted to cheat could bypass its own wrapper. The counter is a convenience; the Network panel is the evidence. That's the reason to learn the two-minute test above rather than take anyone's badge, including ours, at face value.

The Black Rectangle That Doesn't Redact

Edem DOGBE — Wed, 23 Sep 2026 16:45:28 +0000

Documents keep going public with their secrets still inside. The pattern is always the same: someone draws black boxes over the sensitive lines, exports the file, and a reader selects the text under the boxes and pastes it into an email.

The mistake keeps happening because the result looks correct. A black rectangle is black. Nothing on the screen suggests that the words underneath are still there. Here is why they are, how to check your own files in a minute, and what deleting text from a PDF actually takes.

What a PDF page really is

A PDF page is not a picture with text on it. It is a small program, a content stream, that a viewer runs to paint the page. Text is drawn by one set of operators and shapes by another. Here is a page I generated with pdf-lib: one line of text, then a black rectangle over part of it.

page.drawText('Salary: CHF 142000', { x: 40, y: 100, size: 16, font })
page.drawRectangle({ x: 100, y: 92, width: 160, height: 26, color: rgb(0, 0, 0) })

The decompressed content stream comes out as this, trimmed:

BT
0 0 0 rg
/Helvetica-7098480789 16 Tf
1 0 0 1 40 100 Tm
<53616C6172793A2043484620313432303030> Tj
ET
q
0 0 0 rg
1 0 0 1 100 92 cm
0 0 m ... f
Q

The first block sets a font, positions the cursor and shows the string. The hex in the Tj line is the text; it just isn't stored as readable characters. The second block fills a path with black. The viewer paints them in order, so the rectangle lands on top of the text and the eye sees a bar.

The text was never removed. A viewer that extracts text doesn't care about paint order, only about the Tj operators, so it reads the string straight through the bar. I ran pdf.js on that file:

const doc = await pdfjs.getDocument({ data: bytes }).promise
const page = await doc.getPage(1)
const content = await page.getTextContent()
console.log(content.items.map((i) => i.str))
// [ 'Salary: CHF 142000' ]

A rectangle tool or a "black highlight" in a PDF editor typically produces exactly this: one more paint operation, with the content underneath untouched. Some editors have a real redaction command that removes the text. If you're not sure which one you used, test the result.

Check your own file in one minute

You don't need special software:

Open the exported PDF, select all (Ctrl/Cmd+A) and paste into a text editor. Any word from under a box is a leak.
Or search for a word you covered with the viewer's find function. A hit on a blacked-out page is a leak.
Or run the script above, or a text extractor such as poppler's pdftotext, and read the output.

Do this on the file you are about to send, not on the one you edited. Also look beyond the page text. A PDF can carry the same words in metadata, bookmarks, form fields, annotations and attachments, and a file saved incrementally can keep earlier versions of a page in its own bytes. Covering the visible text fixes none of that.

Finding the boxes automatically

We build Vellum, a set of free browser-based PDF tools, and one of them is a checker for exactly this. The way it works shows how the mistake looks from the inside. It never has to guess where text is hidden. It walks the page's operator list from pdf.js and looks for filled paths.

It keeps a running transformation matrix through every save, restore and transform operator, plus the last fill colour set. When it meets a fill operator with a dark colour (relative luminance under 0.45), it records the path's bounding box in page coordinates. It also reads annotations of the Square, Redact and Highlight kinds that have a dark interior colour.

Then come the false-positive filters, which matter more than the detection:

A box must be at least 6 points wide and 3 points high, and cover no more than half the page. Thin rules and full-page backgrounds are not redactions.
The page is rendered at 72 dpi, and the box only counts if at most 2% of its pixels are light. A dark title bar with white text on it is a fill too, but the text is visible, so nothing is hidden and nothing should be reported.
Only then are the text items compared with the box, and a fragment counts as covered when at least 55% of its area falls inside.

The last filter shows where the design comes from. A checker that reports "leak" on every dark rectangle is worse than none, because people stop believing it. So it renders the page and looks at the pixels before saying anything.

It analyses at most 40 pages per document, since the render check is the expensive step, and it reports how many pages it examined. The whole thing runs in the browser tab. The black-box page runs it if you want to try a document without installing anything.

What removing the text takes

Two approaches work.

Edit the content stream. Find the Tj operators under the region and rewrite or delete them, leaving the layout intact. It is the cleanest result: the document stays searchable and the file stays small. It is also the hardest to get right. Text may be split into fragments, use custom encodings, or come from a reused form object, and the covered characters may sit in the middle of a fragment.

Flatten the page. Render each page to an image, paint the black boxes onto the pixels, and build a new PDF from the images. The words under the box stop existing, because the only thing left is a picture of the page with a black area on it.

Our redaction tool takes the second route, and the code is short. In outline (my paraphrase, not the file verbatim):

for (let i = 0; i < src.numPages; i++) {
  // pdf.js renders the page to a canvas at 300 dpi
  const canvas = await renderPage(src, i, { dpi: 300 })
  // black boxes are painted straight onto the pixels
  ctx.fillStyle = '#000'
  for (const b of boxesOnPage(i)) ctx.fillRect(b.x * w, b.y * h, b.w * w, b.h * h)
  // the output document is built from scratch: one image per page
  const page = out.addPage([pageWidthPt, pageHeightPt])
  page.drawImage(await out.embedPng(canvasToPng(canvas)), { x: 0, y: 0, width: pageWidthPt, height: pageHeightPt })
}

Three details in the real implementation are worth copying:

The output starts from an empty document. Nothing is copied from the source PDF, so its objects cannot come along by accident.
PNG, not JPEG. JPEG puts a halo of compression noise around every black letter on white, which is visible on text. The code falls back to JPEG at quality 0.95 only when a page's PNG exceeds 4 MB, which in practice means photo-heavy pages. The longest side is also capped at 6,000 pixels so the browser can allocate the canvas.
Padding around detected text. When boxes come from pattern matching (email addresses, phone numbers, IBANs), the box grows by 35% of the font size horizontally and 15% vertically. A box that misses the edge of a glyph by a pixel leaves a readable sliver of a letter, and a sliver of an "@" is still an "@". Slightly too much black costs nothing.

The price of flattening is that the result is only an image. You lose text selection and search, and screen readers get nothing to read. The file is often larger too. Before you apply, the tool warns that the output becomes an image with no selectable text. Keep the original for the version you still want to edit, and send the flattened copy.

Pattern search has limits too

Flattening solves the destruction. Choosing what to cover is a separate problem, and it needs the same honesty. The pattern detectors run over text lines rebuilt from pdf.js text fragments, so:

an IBAN is accepted only if the mod-97 checksum passes, and a Swiss social security number only if its EAN-13 check digit does, which keeps random digit runs from becoming false positives;
a pattern split across two lines is not found, because matching works line by line;
a page that is a scan with no text layer has nothing to match, so the tool warns that some pages look like scans and points you to OCR. A proposal that silently skipped them would look like a clean result.

Whatever proposals a detector makes, someone has to look at the page before applying it. In the redaction tool, matches are proposed on the preview and nothing is applied until you press the button.

The habit worth keeping

Never trust a redaction because it looks like one. Extract the text from the file you are about to send and search it for the words you meant to hide.

How We Built Browser-Only PDF Tools with WASM

Edem DOGBE — Wed, 02 Sep 2026 01:44:03 +0000

Every online PDF tool asks you to do the same thing before it does anything useful: upload your file. Merge two PDFs, compress a scan, redact a page — step one is always the same button, and it always sends your document to someone else's server first.

For a lot of PDFs that's a fine deal. For a signed contract, a payslip, or a medical report, it is exactly the wrong one. Those files carry information that is regulated in most jurisdictions, and "we delete it afterward" is a promise about timing, not about whether the upload happened. We build Vellum, a set of free PDF tools, on the opposite premise: the file never leaves the device, because there's nowhere for it to go.

This post is about how that's actually implemented — not as a policy statement, but as an architecture that makes the upload structurally impossible.

The architecture

Vellum is a static site. No backend, no API, nothing listening for a file. Everything that used to be "send to server, run a tool, send back" now happens as WebAssembly and JavaScript in the tab.

Three engines carry the actual PDF work, each loaded lazily so a user opening the "rotate pages" tool doesn't pay for OCR they'll never touch:

pdf.js (pdfjs-dist) renders pages to canvas and extracts text/structure. It's Mozilla's own PDF engine, already shipped in every Firefox and Chrome tab — we just load it ourselves instead of trusting the browser's built-in viewer.
pdf-lib manipulates PDF structure directly: merging, splitting, page operations, metadata, form filling.
Tesseract, compiled to WebAssembly via tesseract.js, does OCR. The worker, the WASM core, and every language model are self-hosted under /tesseract/ — nothing is fetched from a CDN:

// src/lib/ocr.ts
export async function createOcrWorker(lang: OcrLang, onProgress?: (p: OcrProgress) => void) {
  return createWorker(lang, 1, {
    workerPath: `${TESS_BASE}worker.min.js`,
    corePath: TESS_BASE,
    langPath: `${TESS_BASE}lang`,
    gzip: true,
    cacheMethod: 'none',
  })
}

That last point matters more than it looks: most tesseract.js examples pull the core and language data from a public CDN. Doing that would mean every OCR run makes an outbound request to a third party — a small crack in a promise that's supposed to be structural, not best-effort.

Encryption, decryption, and file repair go through qpdf, also compiled to WASM, loaded from /qpdf/ with a bundler-ignored dynamic import (Emscripten's loader relies on global side effects that Vite/Rollup would otherwise break):

// src/lib/qpdf.ts
function loadQpdfInit(): Promise<QpdfInit> {
  if (!initPromise) {
    initPromise = import(/* @vite-ignore */ `${QPDF_BASE}qpdf.mjs`).then(
      (m) => m.default as QpdfInit,
    )
  }
  return initPromise
}

A fresh qpdf instance is spun up per operation — the Emscripten runtime isn't reusable after callMain — but the .wasm binary itself sits in the browser's HTTP cache, so repeat use doesn't re-download it.

The part we'd rather not have to say out loud, but which is the whole point: the promise isn't enforced by a privacy policy page. It's enforced by the Content-Security-Policy header, which is the same for every response:

connect-src 'self'

That single directive means the browser will refuse any fetch, XHR, WebSocket, or resource load to a third-party origin — not "we chose not to," but "the browser won't let the page do it even if the code tried." You can verify this yourself with the Network tab open during any operation; that's the whole audit.

The hard parts

None of this is free. A few problems only show up once you actually try to do PDF work client-side.

Redaction that's real, not cosmetic. A black rectangle drawn over text in a PDF viewer is famously not redaction — the text is still there, selectable and copy-pasteable underneath. Vellum's redact tool rasterizes each page to an image, paints the redaction boxes directly onto the pixels, and rebuilds the PDF from the images. The original text object simply no longer exists in the output file:

// src/lib/redact.ts
const rendu = await rasterisePage(src, i, {
  dpi,
  retoucher: (canvas, ctx) => {
    ctx.fillStyle = '#000000'
    for (const b of boxes.filter((z) => z.pageIndex === i)) {
      ctx.fillRect(b.x * canvas.width, b.y * canvas.height, b.w * canvas.width, b.h * canvas.height)
    }
  },
})

The tradeoff is honest and unavoidable: the output has no selectable text anymore. That's the price of redaction you can actually trust.

PDF/A conformance, proven rather than claimed. PDF/A is the ISO standard for long-term archival, and a lot of tools claim to produce it without anything checking that claim. Vellum has two modes. The "faithful" mode preserves selectable text and improves what it can (removes embedded JavaScript, adds an sRGB output intent, flags any non-embedded fonts) but can't guarantee conformance, because that depends on the input document. The "conformant" mode rasterizes every page into an opaque image and reconstructs the file from scratch with no fonts and no dynamic content at all — which is the only mode whose ISO 19005-2 conformance is actually verified: a Node harness (scripts/validate-pdfa.mjs) builds a corpus of deliberately awkward PDFs (unembedded standard fonts, transparency, AcroForms, scanned images) and runs every output through veraPDF, the reference validator. It fails the build if the conformant mode doesn't pass on all of them.

Memory and loading size. Everything runs in the tab's own memory, so the honest limit is "however much RAM the browser gives this page" — a typical office document is comfortable, a two-gigabyte scanned atlas is not. On the loading side, qpdf and Tesseract's WASM binaries are sizeable, so the service worker treats them differently from the app shell: the shell (JS/CSS/HTML) is precached on install, while the WASM engines are cached on first use with a CacheFirst strategy and a 180-day expiration — you pay the download once, not the app-shell cost of bundling megabytes nobody asked for.

Offline without surprising anyone. The PWA can install and keep working with no connection at all, but it never reloads itself out from under a running conversion. registerType: 'prompt' means an available update sits quietly until the user dismisses a non-blocking toast — worth calling out because "autoUpdate" silently swapping the running app mid-task is exactly the failure mode a tool meant for offline, in-progress work can't afford.

What we measured

Claims about competitors are cheap, so we measured instead of asserting. On 2026-08-29 we dropped the same eight-page test PDF into the compression tool of the most-used online PDF services, with the browser's Network tab logging every outgoing request, then resolved each destination host to an IP and its hosting provider.

iLovePDF uploaded the file to api110.ilovepdf.com (OVH, Germany) immediately on drop — before any click on "Compress." PDF2Go uploaded to a Hetzner server in Nuremberg and fired a simultaneous request to Microsoft Clarity for session behaviour analytics. PDF24 Tools uploaded to Hetzner as well, while displaying a "Secure" badge on screen. Smallpdf is marked "not measured" — its native file picker defeated our automated method, and we'd rather leave a gap than guess. Vellum, running the same compression on the same file: zero network requests.

The full protocol and data are at vellumpdf.ch/en/etude. None of the measured services lied about eventually deleting the file — the point the data makes is that deletion happens after the upload, not instead of it.

The business model

The tools are free with no quota, because there's no server cost to ration against. Revenue comes from a separate B2B tier, Vellum Cabinet, aimed at law and accounting firms bound by professional secrecy: a signed processing attestation for their compliance records plus an on-premise build, sold alongside — not instead of — the free public tools.

Try it yourself

The claim in this post is falsifiable in about ten seconds: open any tool at vellumpdf.ch/en, switch off Wi-Fi, and process a file. It works, because nothing needed to leave in the first place — the same test you can run against any competing service, where it won't.

Edem Dogbe, DOGBE MULTISYSTEM, Switzerland