Method

How these tools work

What runs where, what each tool actually does, and where it stops.

What each tool actually does

52 tools, each doing one job, built from seventeen open-source libraries: Mozilla's pdf.js reads and draws PDF pages, pdf-lib writes and encrypts new ones, docx writes Word files, jsPDF typesets them, fflate makes and opens archives, PaddleOCR's PP-OCR models on ONNX Runtime read the text in a picture or a scan, transformers.js runs the Deep reader's GLM-OCR model behind the Pro door, and a Rust MP3 encoder compiled to WebAssembly handles the audio. Every one is listed, with its license, on the licenses page.

No tool downloads a library it does not need. Merging, splitting, compressing and password-protecting never load the page renderer at all, which is why they are roughly a third of the weight of the tools that draw pages.

  • Redact draws every page as an image, paints your marks onto those pixels, and builds a new document from the images alone.
  • Merge and split copy pages, with their fonts and images, into new documents. Nothing is re-drawn, so nothing loses quality.
  • Compress re-encodes the photographs inside a document and leaves the text alone. It does not turn pages into pictures.
  • Protect encrypts the document with AES-128 under the standard security handler, then re-opens the finished file to check that it is really protected.
  • PDF to Word and PDF to Markdown read the positioned text a PDF stores and infer structure from size, weight and alignment — the same inference for both, so they cannot disagree.
  • PDF to image uses the same drawing step as redaction and hands you the pictures.
  • Images to PDF embeds JPEG and PNG data untouched into a new document.
  • HTML to PDF parses markup as data and typesets it. It never renders your markup, so nothing in it can run.

Where the work happens

In your browser tab, on your device. These pages are static files served from a web host; there is no application server behind them and no endpoint that accepts a document — not a slow one, not a rate-limited one, not one that deletes after an hour. Each tool downloads its own code the first time you use it, and after that the file you choose is read by that code, in memory, on your machine.

The heavy work runs in a background thread, so the page stays responsive and a long document does not freeze the tab. If your browser cannot start that thread, the tool says so and runs in the page instead, more slowly.

What does leave this device

Two things do, and neither is your document. The first is a page-view counter served by our own analytics at analytics.pagefabrica.com. Product measurement is limited to eight property-free event names: work_started when you submit a tool, work_completed when it produces a result, and the Deep OCR preview's six — pro_offer_clicked_a or pro_offer_clicked_b (which of two prices was shown when you opened the Pro door), pro_preview_started, deep_model_loaded, deep_work_completed and deep_unsupported. Every one is a name with no input or result properties; the tracker honours Do Not Track, and the compiled event bridge refuses every other name.

The second happens only if you open the Pro door on an OCR tool and start a Deep read: this browser then downloads the Deep reader's model — GLM-OCR, about 660 MB — from Hugging Face's servers, pinned to one published version and checked against digests this site carries. That is a download, not an upload: the request names the model files and nothing about you or your document, the same as fetching any library. The model is then kept in this browser's cache and read from there next time. Nothing else leaves. AI OCR sets out both readers, what each costs and what each refuses.

The “Requests off this site” count includes both. The number in the row of marks is measured in your own tab from the browser's resource timings, and it counts every request that left this origin including our own analytics. The Deep reader's download happens in a background thread whose requests the page's timings cannot see, so the reader counts them itself and reports them to the page, which adds them to the same number — a counter that hid the requests this site makes would be worth less than no counter at all.

How the redaction check is performed

Self-check

  • ✓︎Marked text absent
  • ✓︎No selectable text
  • ✓︎Annotations flattened
  • ✓︎Page count unchanged
  • ✓︎Marks solid black

No file is offered if one fails

After the redacted document has been built, it is opened again from its own bytes, exactly as a stranger receiving the file would open it. Then five things are measured:

  1. every phrase covered by a mark is searched for in the text of the finished file — the result must be zero matches;
  2. the finished file must yield no extractable text at all, on any page;
  3. it must contain no annotations, no form fields, no attachments and no document scripts;
  4. it must have the same number of pages it started with;
  5. each marked rectangle is sampled pixel by pixel in the finished page image and must be solid black.

If any of these fails, no download is offered at all.

How the password protection is checked

The password tool proves itself the same way, because a file somebody believes is protected and is not is worse than one that never claimed to be. After the document has been encrypted, the finished bytes are re-opened five times over:

  1. the file must declare standard PDF encryption in its own trailer;
  2. opening it with no password must fail;
  3. opening it with the password you chose must succeed;
  4. a run of the original page content, kept before anything was encrypted, must be absent from the finished bytes;
  5. it must have the same number of pages it started with.

If any of these fails, there is no download.

What we deliberately leave out

Redaction removes what you mark. It cannot know what is sensitive, so a name you did not mark stays in the document — read the result before you send it. Because pages become images, the finished file is larger and its text can no longer be selected or searched.

Markdown and Word conversion need a text layer. Scanned pages hold a picture of text and cannot be converted by any means other than OCR, which those converters do not perform — OCR a PDF does, and gives the scan back searchable as well. Structure in a converted document is inferred from layout, so headings and tables are a good guess rather than a fact, and the layout itself — fonts, colours, columns, headers and footers — is not carried into Word at all.

Image conversion is limited by your device's memory. A long document at 300 dpi may fail on a phone; the tool will say so rather than produce a broken file.

Compression works on the photographs inside a document and nothing else, so a PDF of pure text has almost nothing to give up. When the saving is not worth a second copy, no file is offered and the reason is named.

Password protection is AES-128 under the PDF standard security handler at revision 4. It is not AES-256, and revision 6 AES-256 protection is not implemented here. If AES-256 is your requirement, use a current desktop PDF tool and verify its reported encryption mode.

The protection still depends on the password. Revision 4 uses legacy password derivation, so short or obvious passwords remain vulnerable to guessing. That is why the tool refuses an empty password, anything under six characters and short runs of digits, and why a long passphrase is the safer choice.

How to use the result

Treat the redaction check as what it is: a proof that the marked text is gone from the file, not a judgement that the file is safe to publish. Look at the finished document before sending it, and keep your original — the redacted copy is the one to share, not the one to archive.

If a tool gets something wrong, tell us what the document looked like. Do not send the document.