Rasterization: The Gold Standard of PDF Redaction

By the SladdPDF team · Published August 23, 2026 · Updated August 23, 2026

To rasterize a PDF is to re-render every page as a flat bitmap image and rebuild the document from those images, so the finished file contains pixels and nothing else. That is why rasterize-based PDF redaction is the strongest guarantee available short of retyping the document by hand: the text layer, the annotations, the hidden objects and the layer structure do not survive the conversion, because there is no longer any structure left for them to survive in. The cost is equally real — the output is no longer searchable, selectable or screen-reader accessible, and the file gets bigger.

What does it mean to rasterize a PDF?

Rasterizing a PDF means re-rendering each page into a grid of pixels — a raster image — and building a new PDF whose pages are simply those images. The visible result is identical: same layout, same fonts, same page size. Everything underneath changes. Before rasterization the page is a recipe for drawing itself; afterwards it is a photograph of the finished dish.

Vector content is described mathematically — this glyph, from this font, at this coordinate — and stays crisp at any zoom. Raster content is a fixed array of coloured dots. The conversion is one-way: you can render vectors into pixels, but you cannot recover the instructions from the pixels they produced.

In redaction terms it is the digital equivalent of a workflow courts have long recommended — print the page, black it out with a marker, rescan, shred the original — without the printer or the scanner.

How does a PDF actually store text?

A PDF does not store a picture of a page. It stores instructions for drawing one, and text is part of those instructions rather than part of any image. Each page carries a content stream: operators that select a font, set a position, then paint a string of character codes. The painting operator is normally Tj or TJ, and the string it takes is literal character data sitting in the file.

Those character codes are not the shapes you see. Each is mapped, through the font's encoding or a CMap, to a glyph in an embedded font program, and the glyph outline is what gets drawn. Fonts are usually subsetted, so the file carries outlines only for the characters actually used.

The consequence is that every PDF page has two independent readers:

• The renderer executes the operators in order and paints pixels on your screen. Objects written later cover objects written earlier — exactly how a black rectangle appears to hide a sentence.
• The text extractor walks the same content stream, ignores every graphic, and reports the character codes. Copy-paste, Ctrl+F, screen readers, indexers and every extraction library take this second path.

Nothing forces those two readers to agree — the root cause of essentially every published redaction failure, and of the more basic problem that a black box is not redaction.

What disappears when a page is flattened to pixels?

When a page is rasterized its entire structure ceases to exist, because the output file has nothing left to hold it in. The renderer runs once, produces an array of pixels, and that array is all that gets written out. None of the following reach the exported file:

• The text layer. No content stream operators, no character codes, no encodings, no embedded fonts. There is no string for an extractor to find, because there are no strings.
• Annotations. A shape, highlight, stamp or comment is either painted into the image or dropped. Either way no object is left to select and delete.
• Optional content groups — the PDF term for layers. They collapse to what was visible at render time, so a hidden layer a viewer could switch back on is never rendered.
• Form fields. Fillable fields and their stored values are interactive objects, not page content, and do not survive.
• Covered and clipped objects. Anything painted under an opaque redaction box contributes nothing to the final pixels. It is not deleted afterwards — it never enters the output.
• Character positioning data. The horizontal advances between glyphs, stored to sub-point accuracy in a normal PDF, are gone. That matters more than most people expect.

The limit worth knowing. Rasterization destroys everything on the page, but document-level metadata such as Author, Title, Producer and creation date lives outside the page content, along with attachments, bookmarks and XMP records. Treat metadata removal as a separate step.

One vocabulary warning, because it causes real accidents: "flatten" describes two operations. Flattening annotations merges markup into the page content but leaves text objects untouched, so the words underneath stay extractable. Flattening to an image is rasterization. Only the second is a guarantee.

Why is rasterization the strongest guarantee?

Rasterization is the strongest form of PDF redaction because it does not depend on a tool correctly finding and deleting the right objects — it discards every object and keeps only the finished picture. Object-level redaction has to be exhaustively complete: every character removed, no fragment left in a font subset, no duplicate in an incremental-update section, no copy in an embedded search index. Rasterization sidesteps that whole class of problem.

The strongest argument comes from research into how object-level redaction fails even when it works. In the 2023 Privacy Enhancing Technologies Symposium paper Story Beyond the Eye: Glyph Positions Break PDF Text Redaction, researchers showed that many redactions leak through character positioning the redaction never touched: the text around a removed passage still records where each glyph sat, to sub-pixel precision, and those measurements constrain what could have filled the gap. Their tool, Edact-Ray, was tested against eleven popular redaction tools including Adobe Acrobat and de-redacted names in hundreds of public documents, among them inspector-general reports and FOIA responses.

That attack needs glyph-positioning data from the content stream. A rasterized page has none — no glyphs, no advances, no positions, only pixels on a fixed grid. Removing text is not the same as removing every trace of it. The NSA's guidance for publishing sanitized documents points the same way: where the source is an image, black it out, make sure the image is flattened with no layers, and only then convert to PDF.

What DPI should you rasterize at? 150 vs 300 vs 600

Rasterize at 300 DPI unless you have a specific reason not to. That number is not folklore: 300 pixels per inch is the minimum US federal agencies must use when digitizing permanent paper textual records under 36 CFR 1236.50, it is the resolution the Administrative Office recommended in 2009 for documents uploaded into the federal courts' CM/ECF system, and it is the minimum the Tesseract OCR documentation asks for.

DPI is the only quality knob rasterization gives you, and it controls three things at once: legibility on screen, print quality and file size. Pixel count scales with the square of the resolution, so doubling the DPI quadruples the pixels on every page — and roughly the bytes needed to store them.

An A4 page at 300 DPI is roughly 2,480 × 3,508 pixels. Federal court guidance is blunt about the upper end: a scanner set above 300 ppi makes documents unnecessarily large, and courts cap the size of PDFs accepted through CM/ECF. Compression matters as much as resolution — a 300 DPI page saved with aggressive JPEG can look worse than a careful 200 DPI one.

What do you lose by rasterizing?

Rasterizing costs you everything a text layer provides: search, selection, copy-paste, machine readability and screen-reader access.

• Not searchable, not selectable. Ctrl+F finds nothing, and quoting a paragraph means retyping it. In a records system or an e-discovery platform, a rasterized document drops out of full-text search entirely.
• Screen readers cannot read it. Every page is an image, so assistive technology has nothing to announce. US federal accessibility guidance is explicit that scanned pages are inaccessible to screen readers, and that OCR plus tagging, reading order and alternative text is required to make such a PDF Section 508 conformant.
• The file gets bigger. Text stored as instructions compresses extraordinarily well; the same text as pixels does not. Expect several times the size of a text-based original, growing with the square of the DPI.
• Quality is now fixed. Vector text stays sharp at 400% zoom; a 150 DPI raster page does not. The resolution you choose at export is the best the document will ever look.
• Interactive features are gone. Form fields, links, bookmarks and layer toggles do not survive, and a digital signature does not carry over — the export is a new document.

Taken together that is a real cost, not a footnote. For anything published under an accessibility obligation, plan the OCR and tagging work before you rasterize, not after someone complains.

Can OCR bring the searchable text back?

Running OCR on a rasterized PDF rebuilds a text layer, but only for the text that is still visible — and that is exactly why it is safe. Optical character recognition reads the image. It has no access to the original file, no content stream to consult, no memory of what used to be there. Where your redaction box is, the image holds a solid rectangle, and a solid rectangle contains no characters. There is nothing to find, so nothing is restored.

That is what makes rasterization practical rather than merely secure: the document is destroyed where it needs to be and searchable everywhere else. Three things to get right:

1. Rasterize at 300 DPI or higher. The Tesseract documentation asks for at least 300 dpi. Redacting at 150 DPI and then OCR-ing gives you a text layer full of errors.
2. Treat the new text layer as a transcription, not the truth. OCR guesses, and it guesses worst on names, account numbers and unusual words.
3. Draw generous, fully opaque boxes. A box that clips the tops or bottoms of letters leaves partial shapes behind, and partial shapes are what a recognition engine is built to interpret.

Note the limit: OCR restores searchability, not accessibility. Tagged reading order, heading structure and alternative text are separate work.

When should you not rasterize?

Do not rasterize when the document must stay searchable, machine-readable or screen-reader accessible and nothing on it is actually secret. Rasterization is a security measure with a usability price, and paying that price for no security benefit is just damage. Reach for something else in these cases:

• Public-facing publications with an accessibility obligation. Government bodies, universities and public-sector suppliers generally cannot ship image-only PDFs. Use object-level redaction, or budget for OCR and tagging afterwards.
• Documents that live in a searchable repository. If the file's job is to be found by full-text search in a DMS, case system or e-discovery platform, an image-only version is close to invisible.
• Fillable forms and signed documents. Rasterizing turns a form into a picture of a form and does not preserve digital signatures.
• Large documents with a hard size limit. Email gateways and court filing systems cap attachment size, and a long rasterized report can blow past limits the original would clear.
• Nothing sensitive to hide. If you only want to prevent editing, rasterizing is a lossy way to do it.

The alternative is object-level redaction in a tool that genuinely removes content, plus a separate sanitize step for hidden data — Adobe Acrobat Pro removes visible content when you apply the redaction marks and offers "remove hidden information" as a distinct operation for metadata, comments, attachments and scripts. Better still, if you own the source document, delete the sensitive passages in the word processor and export a fresh PDF.

How do you rasterize a PDF for redaction?

To rasterize a PDF for redaction you draw the redaction boxes first, then export with an option that converts each page to an image. The order matters: rasterizing a page that still shows the sensitive text just gives you a picture of the sensitive text. In SladdPDF, our free browser-based redaction tool, that export option is Secure mode.

1. Open the PDF in your browser. The file is processed locally with JavaScript and WebAssembly; nothing is uploaded to any server, and the page works offline once loaded.
2. Draw redaction boxes over every sensitive passage. Zoom in for small print, cover the full line height, use Ctrl+Z to undo. Check headers, footers and repeated fields on every page.
3. Choose Secure mode on export. It rasterizes each page after the redactions are applied, so the underlying text, layers and hidden objects are destroyed and unrecoverable. Fast mode draws vector overlays instead and warns that underlying text may in some cases still be extractable — not for sensitive data.
4. Set the image quality. 300 DPI is the right default; drop to 150 DPI only for screen-only drafts.
5. Enable metadata removal so the title, author, creation tool and hidden tags go too. Rasterizing the pages does not clear document properties on its own.
6. Verify the export. Open the finished file, press Ctrl+A then Ctrl+C, paste into a plain text editor. On a correctly rasterized document nothing comes out at all. That empty paste is the proof.

Being straight about the limits: the free version of SladdPDF redacts with no page limit but exports at standard resolution, and Pro — a paid licence key — unlocks high-resolution 300 DPI export. For batch work or mandated redaction logs, a desktop tool such as Adobe Acrobat Pro is the better fit.

One last step people skip: rasterization is thorough about the page and indifferent to everything around it, so finish with our guide to removing metadata from a PDF. A page made of pixels with the original author's name still in the document properties is not a finished redaction.

This article is general guidance, not legal advice.