DEV Community: Edem DOGBE

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