I was building another PDF tool. Then I realized the interesting problem isn't PDFs — it's scanned documents.

I started PDFKit with a pretty boring idea.

Build a useful PDF toolkit.

Merge.

Split.

Compress.

Edit.

Create.

Protect.

Redact.

All client-side.

Useful? Sure.

Differentiated? Not really.

The internet is absolutely drowning in PDF tools.

Then I started looking more closely at redaction.

The problem I didn't account for

Most PDF redaction workflows start with text extraction.

You load the PDF, extract its text, search for the sensitive information, find its coordinates, cover those coordinates, and generate a new PDF.

That works when the PDF actually contains text.

But consider an old legal document that was scanned.

Or a medical record from years ago.

Or a FOIA response.

Or a photocopied form.

Visually, you can read:

John Smith

But to the PDF parser?

There is no “John Smith.”

There is an image.

So suddenly the entire redaction workflow changes.

OCR solves the first problem. Then creates another.

The obvious answer is OCR.

Run OCR → find the text → redact it.

But if the document contains sensitive information, the easiest implementation is also the one I don't particularly like:

Upload the document to a server.

Run OCR there.

Send the result back.

That works technically, but it undermines the privacy reason someone might want a local redaction tool in the first place.

So I'm experimenting with a different architecture:

OCR inside the browser.

No PDF upload required for the OCR step.

The page gets rendered locally.

OCR runs locally.

Matches are found locally.

Redaction happens locally.

The output is generated locally.

The browser can then produce a certificate containing the processing details and hashes of the original/output files.

And this is where it gets difficult

I initially thought OCR would be the hard part.

It isn't.

The hard part is deciding what to cover.

OCR gives you bounding boxes.

PDFs have their own coordinate systems.

Scanned pages can be rotated.

Documents can be skewed.

Characters can touch each other.

OCR can split words incorrectly.

A low-resolution scan can produce slightly wrong coordinates.

And redaction has a very different tolerance for mistakes than almost every other feature I've built.

If a PDF compressor makes a slightly bad tradeoff, you get an ugly PDF.

If a redaction box is slightly too small, you may expose information that was supposed to disappear.

That's not an acceptable “minor bug.”

So I'm changing how I'm building this

Instead of treating OCR as:

“Add Tesseract and we're done.”

I'm treating the pipeline as:

OCR → candidate detection → conservative coverage → output verification

And I'm trying to build tests around the cases most likely to break it.

Not just clean screenshots.

Messy scans.

Different resolutions.

Rotated pages.

Multiple occurrences.

Text near page edges.

Names split across OCR results.

Documents with no text layer at all.

The funny part

The original seven-tool PDF app is still there.

But now I think the actual product is much narrower:

Private redaction for documents that other PDF redaction tools can't easily search.

That's a much more interesting problem to build around.

PDFKit isn't public yet.

I'm looking for early users who have real scanned PDFs they can safely use for testing.

Especially if you've worked with legal documents, compliance, records, research, or document-heavy workflows.

I'd rather find the ugly failure cases now than discover them after launch.

What is the nastiest scanned-document edge case you'd test first?