pdf-redactor

What it does

pdf-redactor is a small pure-Python module built on pdfrw that scrubs a PDF's text layer, plain-text annotations, link target URLs, the document information dictionary and embedded XMP metadata. You supply filter functions or regular expressions and it writes a new PDF with matched text substituted and metadata rewritten. It rewrites the underlying text in the content stream rather than drawing boxes over it, so matched characters genuinely leave the text layer — but images and other resources are untouched.

Best for: Developers who need scripted, repeatable text-layer and metadata scrubbing as one step in a pipeline, and who will review exactly what the tool does and does not touch before trusting it with sensitive material.

Worth knowing: It is explicitly incomplete and the project says so. Images, embedded files, multimedia, scripts, rich-text annotations, forms, internal object names and digital signatures are not examined. The command-line script does nothing to a PDF without custom filter functions, and replacement characters may be missing from the embedded font. Last touched in 2024 and still versioned 0.0.1. The removal scope belongs beside the redaction badge as well as in the prose: this substitutes text in a text layer and handles selected metadata and annotations rather than sanitising a PDF completely, and the project explicitly excludes numerous embedded components while warning about fonts and compression. The bare command-line entry point performs no useful filtering without custom functions. Local processing is an architectural assessment rather than an upload test, and the absence of a hosted product does not mean the operator has no privacy policy. The package release date and repository activity are different facts: PyPI 0.0.1 was released on 19 April 2021, and the 2024 last-activity claim would need a dated commit reference. CC0 licensing and the embeddable-library classification are supported.

Details, and where each comes from

Vendor statements, our own reading of their pages, and the things nobody has established yet, each answered separately. Where we have not confirmed something it says so rather than guessing, and a row nobody has established is greyed out.

Versions covered

Windows · macOS · Linux

Website

github.com

Requires an account

Not applicable

Watermark on the free tier

No

Maximum file size

Not verified

Batch processing

No

Data residency

Self-hosted

Open source

Yes

Self-hostable

Yes

Licence

CC0-1.0

Redaction

Removes the content

Programmatic access

Embeddable library

Last availability check

Responded in 396 ms 16 October 2026

Checked automatically by our own runner, not reported by the vendor. 96.7% of our last 30 checks got a response.

What the vendor says

Claims are labelled rather than repeated as fact. Where we have checked something ourselves, it says so and shows when. Checked means we read the vendor's own page and it says what we recorded — not that we tested the behaviour, unless the note says we did.

• “A general-purpose PDF text-layer redaction tool, in pure Python, by Joshua Tauberer and Antoine McGrath.”

  Checked by us — the source says this Read 22 September 2026

  Confirmed verbatim — the claim is the first line of the README, unaltered — and unlike the other two in this batch, the wording is a description of what the tool is rather than a promise about what it does, so the test is what settles the useful part. That test found it removes content: it matches the text layer by pattern and rewrites the characters out. The README's own Limitations section is the thing a reader most needs and the claim does not carry, and it is unusually candid: the tool does not look at embedded files, multimedia, scripts, rich text annotations, forms, internal object names or digital signatures, and it says plainly that ensuring the input only uses capabilities the tool understands is 'your responsibility'. It also warns that some PDFs need qpdf to uncompress the streams first, and that fonts without full glyph coverage can mean replacement text does not render. So: confirmed for what it is and for what we observed, with the caveat that its coverage is narrower than the word 'redaction' suggests.

  Standing: Re-read and matched byte for byte

  Check it yourself: the source, the SHA-256, and how we checked

  Read

  https://github.com/JoshData/pdf-redactor

  From

  the text a browser renders

  SHA-256

  7da3483925d84d84713a18797e709df7905400443f4350d2b181fa62206a2f70

  Note

  no saved artifact matches this hash, so the normalised comparison has nothing to normalise towards. The raw response and a render both fail to reproduce it; the GitHub page embeds fingerprinted asset names that change.

  How we checked: Re-verified verbatim on 2026-09-22: https://github.com/JoshData/pdf-redactor re-rendered in headless Chrome with scripts/render-page.mjs and the claim's wording found in the rendered text. Originally verified on 2026-09-21. sourceHash is the SHA-256 of the re-rendered text, held as rv-github-com-JoshData-pdf-redactor-30a22d1d.txt.

  What this hash proves, and what it does not

• “Graphical elements, images, and other embedded resources are not touched.”

  Checked by us — the source says this Read 22 September 2026

  Confirmed verbatim: the sentence appears unaltered in the README's list of limitations. It is the most consequential sentence in this entry and one of the most consequential in the index, because it bounds the same tool's redaction claim: a redaction performed with pdf-redactor leaves every image, embedded file and graphic untouched, so a scan of a redacted page still shows what was removed. The claim is recorded in the capability tier rather than the redaction tier because of how the ranking matched it, and this finding says plainly that it belongs in a reader's mind next to pdf-redactor's redaction entry, which the index already carries.

  Standing: Re-read and matched byte for byte

  Check it yourself: the source, the SHA-256, and how we checked

  Read

  https://github.com/JoshData/pdf-redactor

  From

  the text a browser renders

  SHA-256

  7da3483925d84d84713a18797e709df7905400443f4350d2b181fa62206a2f70

  How we checked: Re-verified verbatim on 2026-09-22: https://github.com/JoshData/pdf-redactor re-rendered in headless Chrome with scripts/render-page.mjs and the claim's wording found in the rendered text. Originally verified on 2026-09-21. sourceHash is the SHA-256 of the re-rendered text, held as rv-github-com-JoshData-pdf-redactor-30a22d1d.txt.

  What this hash proves, and what it does not

• “This Python module is a general tool to help you automatically redact text from PDFs.”

  Checked by us — the source says this Read 22 September 2026

  RE-QUOTED 2026-09-22: this claim previously read "A general purpose PDF text-layer redaction tool: patterns are matched against the text layer and the matched characters are rewritten out of it." — our characterisation rather than the vendor's wording, so a reader could not tell a quotation from a summary. The vendor's own sentence is now in the claim field and what we read from it follows here. The boxed string is gone from the saved file; the lines 40pt above and below it survived, as did the untouched second page, so the removal is localised. The output contains zero image XObjects, so nothing was rasterised: the marked text is deleted from the page structure and a solid fill is drawn in its place. qpdf reports no errors and agrees on every marker. One observation that surprised me and is recorded rather than explained away: the replacement text supplied to its filter did not appear in the output either, so it appears to remove matched characters rather than substitute them. That is consistent with what the tool is for. Its documented limits are unchanged and untested here — images, embedded files, forms and signatures are not examined, so a redacted scan may still show everything.

  Standing: Re-read and matched byte for byte

  Check it yourself: the source, the SHA-256, and how we checked

  Read

  https://pypi.org/project/pdf-redactor/

  From

  the text a browser renders

  SHA-256

  7da3483925d84d84713a18797e709df7905400443f4350d2b181fa62206a2f70

  How we checked: Re-verified verbatim on 2026-09-22: https://github.com/JoshData/pdf-redactor rendered in headless Chrome with scripts/render-page.mjs, and this sentence found in the rendered text. ALSO RE-QUOTED on the same date: the claim field previously held our own summary of this page rather than the vendor's sentence, which made it impossible to verify by quotation — the schema's own words are "we do not repeat a vendor's claim as though it were our own finding", and the reverse holds too. sourceHash is the SHA-256 of the rendered text, held as rv-github-com-JoshData-pdf-redactor-30a22d1d.txt.

  What this hash proves, and what it does not

Each claim is quoted from the vendor's own pages. This section describes what we have and have not checked — it is not a judgement about anyone.