BASALT · JOURNAL

How to permanently delete text from a PDF

2026-08-06 · permanently delete text from pdf

Deleting text from a PDF and making text stop appearing on the page are different operations, and most tools do the second one. The page looks right, the file still contains the words, and the difference only surfaces when someone runs a text extractor.

This article describes what permanent deletion actually involves at the file level, why the usual approaches fall short, and how to confirm the text is gone rather than hidden.

Why a PDF is hard to edit in the first place

A PDF is not a document in the sense a word processor means. It is a set of numbered objects with a cross-reference table telling a reader where each object starts, and the visible page is produced by executing a content stream: a small program of graphics operators.

Text is drawn with the text-showing operators Tj, TJ, ', and ". Their operands are strings of character codes that index into a font's encoding to select glyphs. Positioning comes from the text matrix, set by operators like Td and Tm, and from kerning adjustments embedded in TJ arrays. There is no notion of a paragraph, a word, or a line. There are glyph runs at coordinates.

That is why deletion is not simple. Removing a name from the middle of a TJ array means removing the corresponding character codes, then fixing the run so the text that follows still lands where it did before. If you get the offsets wrong the rest of the line slides. If you remove nothing and just draw over it, you have not deleted anything at all.

The three things people try

Drawing a black rectangle. Any markup tool can do this, including Preview. It appends a fill operator to the content stream. The earlier text operators still execute, still hold the characters, and still respond to search and copy. This is the failure behind a long list of public embarrassments, several of which are collected in famous redaction failures. Preview specifically is covered in why Preview is not safe for redaction.

Deleting with a PDF editor's text tool. Editors that let you click into a paragraph and delete words are genuinely modifying the content stream, which is more than drawing. Two problems remain. First, many of them save incrementally, which means the edited objects are appended and the originals stay in the file. Second, they edit the page and nothing else, so the same text in a comment, a form field, an attachment, or the metadata is untouched.

Flattening or printing to PDF. Re-rendering the page as an image does destroy the text layer, which is real. It also destroys searchability, bookmarks, links, Bates numbers, and resolution, and it gives you no record of what was removed. It is a last resort, not a method.

What permanent deletion requires

Four things have to be true of the output file.

The operands are gone. The character codes for the deleted text must not appear in any content stream. Surviving text in the same run must be re-emitted with corrected positioning so the page layout is preserved. This is a glyph-level edit, not a string search and replace, because the same visible word can be encoded differently across fonts and subsets.

Every parallel copy is gone. The same text can exist in places that have nothing to do with the page:

• The document information dictionary, holding /Title, /Author, /Subject, and /Keywords.
• The XMP metadata packet, which is XML and often carries the original filename, the authoring account, and version history.
• Annotation objects, where a comment's /Contents value can quote the passage it annotates.
• AcroForm field values, stored separately from the appearance stream that renders them.
• Embedded file attachments, which are whole files carried inside the PDF.
• /ActualText and /Alt entries in tagged PDFs, which supply text to screen readers and extractors.
• Optional content groups, meaning layers that are present but switched off.
• Structure tree elements, bookmarks, and named destinations, which can carry heading text.
• Page thumbnails and cached appearance streams generated before the edit.

Hidden data in PDFs goes through these in more depth.

The file is rewritten, not appended. PDF supports incremental updates: a save can append new objects and a new cross-reference section and leave everything before it untouched. A viewer resolves to the latest version of each object. A parser reading the file linearly can recover the earlier one. If your output file is the input plus a small delta, the deleted text may still be sitting in the first half of the bytes. Permanent deletion means a full serialization: rebuild the object graph from the edited state and write one generation, with no stale objects, no orphaned streams, and no prior cross-reference chain.

Compression does not hide anything. Content streams are usually Flate compressed and objects are often packed into object streams. Neither is encryption. A parser inflates them without effort. Text you cannot see in a hex editor is not text you have deleted.

Verifying that it worked

The claim "the text was deleted" is only worth what the check behind it is worth. A tool reporting success is describing its own in-memory state using the same code that produced the output.

The check that means something reads the file you are about to send:

1. Extract all text from the output with a parser that had no part in writing it. Search for the deleted strings.
2. Dump the metadata, both the information dictionary and the XMP packet, and search those.
3. List annotations and read every /Contents value.
4. List form fields and read every value.
5. List embedded files and inspect each one.
6. Compare the output size and structure to the input. A near-identical size with a small tail is the signature of an incremental save.

How to verify a PDF redaction sets out the commands. A useful additional signal is determinism: run the same deletion on the same input twice and compare checksums. Identical output means the tool is doing something defined rather than emitting whatever happened to be in memory. See reproducible redaction.