Take any PDF. Draw a black rectangle over a line of text in a viewer that lets you annotate. Save it. Open it again and drag-select across the rectangle.

The text comes back.

That is the entire reason I built a PDF tool site, and it is also the first thing I got wrong.

A black box is a drawing, not a deletion

An annotation is an object layered on top of the page content. The characters underneath are still there, in the content stream, encoded exactly as they were before you covered them up. Select-all still finds them. Copy still copies them. Any text extractor still returns them.

Actual redaction means the characters stop existing in the file. Not hidden, not covered, not rendered white-on-white — gone from the content stream, so that extraction returns nothing.

I built the redaction tool around that distinction, and then I made the checker report a number instead of a picture. Counting characters inside the marked areas turns out to be the only way to tell a real deletion from a good-looking one.

Three different zeros

This is the part that took me longest to get right, and it is the part most redaction tools skip.

If the checker says "0 characters inside the marked areas," that sentence can mean three completely different things:

  1. The text is gone. The page had a text layer, you marked it, and now extraction returns 0. This is the result you want, and the report calls it CLEARED.
  2. There was never a text layer. The page is a scan. Every pixel is an image; there are no characters to find in the first place. The tool reports NOTHING TO MEASURE, because the 0 is the absence of a measurement, not a clean result. A scanner output can look identical to a properly redacted page and mean the opposite thing — one has no text because it never did, the other has no text because you removed it.
  3. You drew the box on empty space. Same 0, same false comfort. The text you meant to remove is three lines down.

The first version of my checker merged all three into a single "0" with a green tick. That is a security product telling you what you want to hear. The current version reports the source page's character count next to the output's, so a scan and a clean redaction can never look the same.

There is a fourth result, and it is the ugly one: the marked page still hands back extractable text after processing. The report says so in plain words and tells you to treat the output like the original. It has happened in testing. I would rather the tool say that than round up to success.

What actually happens to the file

The redaction runs locally: the page is rendered to a canvas at 2× (about 144 DPI), the marked pages are rebuilt as JPEGs at quality 0.9, and the result is assembled into a new PDF. Pages you did not mark are copied through with their original text layer intact.

That has a consequence the tool states on the report rather than hides: a rebuilt page is an image, so everything on it stops being selectable — including the text that was not inside a box. If you need the rest of the page to stay searchable, you cannot have that and a destroyed text layer on the same page. Pick which one matters for this document.

The leak nobody looks at

Redaction is about what is visible. Metadata is about what is attached.

I stripped Title, Author, Subject and friends, and the file still carried the old title. The cause: pdf-lib removes the catalog's reference to the XMP packet, but the packet itself survives as an unreferenced indirect object inside the document. Delete the pointer and the body stays.

The second mistake was the check. I searched the output bytes for x:xmpmeta and found nothing, so I called it clean. The object was compressed. A byte search over a deflated stream tells you nothing at all — and this is exactly the kind of false pass that makes a verification step worse than no verification step.

The fix was to enumerate every indirect object after stripping, decompress each stream (UTF-8 first, then deflate, then raw deflate), and count the ones that still contain an XMP packet. Streams over 5 MB are reported as unscanned rather than silently skipped, because "I did not check this" and "this is clean" are different answers.

On my test file: 1,634 bytes in, 766 out, no XMP left. Compressed variant: 1,256 to 754.

Two more surprises, both about what tools quietly drop

Rebuilding a PDF is a destructive operation and the destructive part is not always where you expect.

PDFDocument.create() plus copyPages does not carry Author, Title or XMP into the new document — so a merge tool built this way produces a file with the contents of both inputs and the metadata of neither. It also stamps its own Producer and Creator as pdf-lib (...). If you were merging to preserve a document's provenance, you did not.

Same for splitting: each part is a fresh document, so each part arrives with no author and no title, whatever the original had. A tool page claiming otherwise is a page contradicting its own code.

The page-level limits are equally unglamorous: splitting one page per file caps at 50 pages, converting to JPG caps at 100, redaction caps at 50, and every tool caps the upload at 100 MB. These are browser limits, not policy — past that point memory pressure starts killing tabs, and a tool that crashes halfway is worse than one that refuses up front.

How to check that nothing is uploaded

This is the claim everything else rests on, so it should be falsifiable in ten seconds rather than taken on trust.

Open the tool, open the browser's Network tab, and drop a file in. You will see no request carrying your document. What you will see is static assets, and Cloudflare's analytics beacon, which the host injects into every page it serves — that is the CDN counting visits, not your file going anywhere. Clear the log, process the file, and watch it stay empty.

Five tools, all of them local

Everything above is implemented in the browser with pdf-lib and pdf.js. No server, no queue, no upload step, because there is nothing to upload to.

  • Redact a PDF without uploading it — draw boxes, rebuild the marked pages as images, get a report that separates the three zeros. Not a certification, not legal advice, and not a substitute for a compliance workflow that requires one.
  • Strip metadata from a PDF — Info dictionary and XMP, verified by decompressing every object rather than trusting the pointer deletion.
  • Merge PDFs in the browser — page contents carried, metadata deliberately not.
  • Split a PDF into single pages — one file per page or fixed ranges, zero-padded names so part10 sorts after part9 and not before part2.
  • Convert PDF pages to JPG — 144 or 216 DPI, quality 0.92 fixed, one download per page or a single ZIP.

Disclosure: these are my own tools. No affiliate links, nothing paid, no account required.

If you need redaction that survives opposing counsel, this is not that product, and I would rather say so here than in a support email. What it is: a local check you can run before you send a file you are not sure about.