A PDF workflow can stay responsive: a reproducible Web Worker test

PDF work is an easy way to make a web app feel stuck. Parsing a file, finding candidate data,
rendering pages, and rebuilding an output can all be CPU-heavy. If that work runs on the UI
thread, a progress label does not make the interface responsive—it only describes the freeze.

I wanted a small test that I could repeat in a browser:

1. use a PDF containing only synthetic personal-data markers;
2. run an automatic-redaction flow that delegates the output work to a real Web Worker;
3. inspect the browser evidence; and
4. verify the downloaded PDF separately.

This is evidence for one controlled workflow, not a universal claim that every document is
detected perfectly or that every possible PDF trace is removed.

The controlled file

The three-page test PDF contains deliberately fake values:

• [e-mail]
• [phone]
• 4111 1111 1111 1111
• 00000000T
• ES82 0000 0000 0000 0000 0000

Do not use real personal data in a public demonstration. Keep an original protected and work on a
copy.

What runs in the Worker

The test uses PriviTools PDF Auto-Redactor.
The page reads the selected file into an ArrayBuffer, but the expensive output stage is handed
to auto-redact-worker.ts with:

• the PDF bytes;
• the approved boxes, after the user reviews the findings; and
• a message channel for page-level progress and the resulting bytes.

The Worker has no DOM access. It returns messages to the page instead of updating the interface
directly. In DevTools, the worker bundle appears as its own browser resource; that is the useful
distinction here, not merely a UI label claiming that work is “local.”

Reproduce the browser flow

1. Load a synthetic PDF

Open the Auto-Redactor and select the test file. The interface makes an important limitation
visible before processing: pattern detection can miss data or flag harmless content, so the result
must be reviewed before sharing.

2. Choose what to scan, then review—not blindly redact

For this test I enabled the categories represented by the synthetic file: email, phone, card
number, IBAN, and national ID. The scan produces a review list. Untick anything that should
remain; a detector cannot understand the business context of every value.

The browser view also makes the worker resource observable while the flow runs. That is a
reproducible implementation check: the main page initiates the work, the worker processes the
approved boxes, and progress/result messages come back to the UI.

3. Generate a new copy and check that copy

Click Redact & download, then open the downloaded file independently. Do not treat the preview
or the button state as the security result.

For an additional check on macOS or Linux, search the final copy’s text layer for known markers:

pdftotext final-copy.pdf - | rg 'ana\.santos@example\.invalid|202-555-0147|4111 1111 1111 1111|00000000T|ES82 0000'

In this controlled run, the command produced no matches for those markers. A raw-byte check also
produced no matches for the same list:

strings final-copy.pdf | rg 'ana\.santos@example\.invalid|202-555-0147|4111 1111 1111 1111|00000000T|ES82 0000'

No output is a useful signal, not a blanket guarantee. It does not inspect every page visually,
nor does it replace checks for annotations, form values, embedded files, links, or metadata.

What this proves—and what it does not

This demonstration establishes four narrow facts for the recorded test:

1. the sample file contains the known synthetic markers before processing;
2. the UI requires a review step before redaction;
3. the redaction job is dispatched to a browser Web Worker; and
4. the selected markers were absent from the downloaded copy’s extractable text and printable raw strings in this run.

It does not establish that every identifier in every font, scan, form, annotation, language, or
future version of the application will be found. Image-only PDFs need visual review; OCR and later
processing can create a new text layer, so they need verification again after that step.

A practical release checklist

Before sharing a redacted PDF:

1. review every proposed finding and every page;
2. inspect the final downloaded copy in a second viewer;
3. search, select, and copy from the redacted areas;
4. run a text-layer and raw-byte check using controlled markers where possible;
5. check metadata, comments, forms, attachments, and links separately; and
6. retain the original securely and distribute only the checked copy.

The larger implementation notes—including why this project moves PDF work into Workers and how it
tests outgoing requests—are in Processing PDFs in the browser without freezing the UI: Web
Workers and local data.

The point is not to call a browser workflow “private” or “safe” by slogan. It is to make the path
inspectable: review the candidate data, observe the Worker, create a new copy, and verify the file
you are actually going to share.