Strip Text Streams

The history of electronic document security is riddled with catastrophic redaction failures involving high-profile government agencies, international intelligence services, and global law firms. In almost every case, the failure stemmed from a fundamental misunderstanding of the PDF graphic model.

In PDF architecture, a page is rendered by executing an ordered sequence of drawing operators inside the /Contents stream. If an author draws a filled black rectangle over a paragraph, the PDF viewer first renders the text glyphs, and then paints the opaque rectangle on top of them. Visually, the text appears obscured. But structurally, the text operators (BT, Tf, Tm, Tj, ET) remain untouched in the underlying content stream.

Any recipient can simply drag their cursor across the black box, copy the text to their clipboard, or paste it into a text editor to read the 'redacted' information instantly. Furthermore, search engines and screen readers parse the text stream directly, rendering visual overlays completely useless for data protection.

Achieving genuine vector-level text removal requires surgical deconstruction of the PDF page content stream. Under ISO 32000-1 Section 9, all text rendering takes place within designated text objects enclosed between BT (Begin Text) and ET (End Text) operators.

Within a text block, characters are positioned and drawn using specific operator sequences:

1. /Font size Tf: Selects the active font resource and point size.

2. Tm (Text Matrix) and Td (Text Move): Establish the 2D coordinate transformation matrix that positions characters on the Cartesian plane.

3. Tj, TJ, ', and ": Draw character strings or arrays of strings with kerning offsets.

To genuinely remove text from the content stream, an engine must decompress the /Contents stream (typically encoded via FlateDecode / Zlib), lexically tokenize the PostScript-like operator stream, calculate the bounding box of each glyph sequence using the font's metric tables, and excise or replace the target text tokens. By physically stripping the character codes from the Tj/TJ operators and recompressing the stream, the text is permanently obliterated from the document structure.

While content stream parsing is theoretically straightforward, production PDF files introduce immense typographic complexity through font subsetting and custom ToUnicode CMaps. When a PDF is created, authoring applications rarely embed full fonts; instead, they embed a minimal subset of glyphs assigned to arbitrary internal character codes (e.g., character code 1 might map to the letter 'E', while character code 2 maps to 'x').

If the document's /ToUnicode CMap is missing, corrupt, or non-standard, parsing character strings directly from Tj operators becomes unreliable. In such scenarios, attempting naive string replacement can inadvertently corrupt surrounding typography, shift line spacing, or leave phantom glyph fragments visible on the page.

Our application addresses this challenge with dual-engine flexibility: for well-structured digital documents, it performs precise coordinate-based content stream excision; for complex documents with corrupt CMaps or scanned visual text, it provides high-resolution irreversible burn-in.

When handling scanned paper records, court filings with embedded OCR layers, or PDFs with heavily obfuscated vector outlines, the only mathematically foolproof method of text elimination is high-resolution pixel-level burn-in.

In this workflow, our engine renders the target PDF page onto an isolated, ultra-high-resolution HTML5 Canvas at 300 DPI (print publication quality). The specified text coordinates are overwritten with solid color pixels, physically replacing the pixel data in the canvas memory buffer. The page is then re-encoded as an uncompressed or losslessly compressed image XObject embedded inside a clean, newly synthesized PDF page.

Because the original content stream, text layer, OCR invisible text, and vector glyph tables are completely discarded and replaced with a single rasterized bitmap, there is zero residual vector data, no hidden OCR text, and no slack metadata. It provides an absolute, forensically impenetrable guarantee of text destruction.

Sanitizing sensitive records for litigation, FOIA compliance, or regulatory filing under GDPR and HIPAA presents zero margin for error. Uploading unredacted discovery documents, trade secret filings, or patient medical records to third-party web servers creates immediate regulatory breach liabilities and waives attorney-client privilege in many jurisdictions.

2run.tools eliminates these catastrophic risks by executing 100% of the text removal and redaction pipeline inside your browser's local sandbox. Powered by WebAssembly and client-side JavaScript, your source document is loaded into local RAM, sanitized, and recompiled without a single byte departing your machine. You can even disconnect your network cable and perform the entire redaction in a completely air-gapped environment.