Redact first, then translate. Redacting afterwards means the confidential text has already left your building, and it means doing the work twice — once in each language, across inflected forms that plain string search will miss. The mechanical hazard is worse: in most documents a "redaction" is a black rectangle drawn on top of text that is still present in the file, fully readable by any text extractor. A translation pipeline reads the text layer, not the picture, so covered-but-present text is translated and can resurface in the output when the page is re-rendered and the box no longer lands where it used to.
This guide covers what a redaction box actually is inside a file, what happens to it during translation, and a sequence that holds up under verification.
Ordering Is a Control, Not a Preference
Redaction is data minimisation applied at the document level. Its value is that the sensitive content never reaches the next processor. Apply it after translation and you have kept the paperwork and thrown away the control — the names, account numbers and deal terms were in the payload sent to the vendor and to whatever sits upstream of the vendor.
There is a second, more practical argument. Redacting the target language means locating the same spans again in text that has changed shape. A party name that appears fourteen times in the English source may appear in four inflected forms in the Polish translation, and a search-and-replace pass over the nominative will silently miss the genitive. Numbers change separators, dates change order, and an address may have been reordered entirely.
Doing it once, at source, in the language you actually read, is both safer and cheaper. Everything below assumes that order.
What a Black Box Is Inside a PDF
A PDF page is a content stream of drawing operators. Text is placed by operators that position a font and emit glyph codes; a filled rectangle is a separate operator painting a shape. Painting a rectangle over text changes nothing about the text — only what a renderer draws last.
That produces three failure modes, all common:
Annotation-level boxes. A square annotation or opaque highlight sits in the page's annotation array. Delete it and the text is visible again. Extractors ignore it entirely.
Flattened boxes. Flattening merges the annotation's appearance into the page content stream. It looks permanent and is not: the text operators are still underneath.
Incremental save history. PDFs can be saved by appending changes to the end of the file. Earlier revisions — including the unredacted page — remain in the byte stream.
True redaction removes the glyphs from the content stream and rewrites the page. Everything else is a visual effect. PDF/UA specification work is a reminder that the visible page and the structural content are separate by design.
Re-Rendering Moves the Box, Not the Text
Now put a cosmetically redacted PDF through translation. The extraction stage reads text objects, including the ones under the rectangle, because the rectangle is not text and has no semantic relationship to what it covers. The covered content is translated along with everything else.
Then the document is rebuilt. The rectangle is a graphic anchored to page coordinates. The text around it is not: translated text reflows, and expansion is real — English into German or Russian commonly runs longer, and the line that used to end at the box now ends somewhere else. The box stays put. The text moves out from under it.
The result is a document that looks redacted in the source and is partially unredacted in the target, with the sensitive span now sitting beside a black rectangle instead of behind it. This is not a bug in any particular tool. It is what happens when a visual overlay is asked to survive a layout change. Format fidelity work, covered in PDF translation and format fidelity, preserves structure faithfully — including structure you wanted gone.
Office Formats Hide Text in More Places
DOCX, XLSX and PPTX are ZIP containers of XML parts, defined by Office Open XML. Text can persist in several parts that never appear on screen.
In Word: hidden text carries a vanish property and renders as nothing while remaining in the XML; white-on-white text is fully present; unaccepted tracked deletions store the original wording inside deletion elements; comments live in their own part; and document properties, custom XML parts and embedded objects each carry their own payload.
In Excel: hidden rows, columns and sheets are hidden, not removed. Cached formula results persist. A pivot cache can retain a copy of source data whose sheet was deleted, and defined names can reference ranges nobody remembers creating.
In PowerPoint: objects dragged off the canvas remain in the slide XML, speaker notes are a separate part, and a slide master or layout can hold text a viewer never sees.
None of this is exotic. All of it extracts cleanly, and all of it will be translated.
Scanned Documents Carry Two Copies
A scanned PDF is an image plus, usually, an invisible OCR text layer positioned behind the image so the document is searchable. Redaction has to address both, and the failure modes are asymmetric.
Draw a vector rectangle over a scanned page and you have covered pixels in an image XObject that remain intact in the file, plus an OCR layer that still holds the recognised characters. Extraction pulls the OCR text; a cropping tool can recover the pixels. Conversely, redact only the OCR layer and the visible words are still legible in the image, which any downstream OCR pass — including the one your translation vendor runs — will happily read again.
The reliable approach for scans is to redact the raster: remove the pixels, save the image, then re-OCR the redacted image so the text layer is regenerated from what is actually there. Regenerating rather than editing means the two representations cannot disagree. Practitioners work through the pitfalls of this in a thread on translating scanned PDFs.
Placeholder Tokens Beat Blank Space
Once the sensitive text is genuinely removed, you have a choice about what to leave behind, and blank space is the worse option.
Removing a party name mid-sentence leaves a fragment. Machine translation handles fragments badly: a missing subject invites an invented one, gendered articles are guessed, and a truncated clause can be smoothed into a fluent sentence that says something the original did not. A gap also destroys the audit trail — nobody can later tell how many items were removed or where.
Replace each removed span with a stable token instead: a bracketed identifier such as REDACTED-01, unique per removed item, consistent across every occurrence of the same entity. Add those tokens to the do-not-translate list so they survive intact, which is exactly the mechanism described in terminology control for legal and financial translation.
Tokens keep sentences grammatical, keep counts verifiable, and let you re-associate values later in a controlled environment if the workflow requires it.
A Sequence That Holds Up
Work from a clean copy. Save-as to a new file rather than editing in place, which collapses incremental revision history rather than appending to it.
Inventory the file. Determine whether there is a real text layer, a scan, or both, and list the hidden containers relevant to the format — tracked changes, notes, hidden sheets, off-canvas shapes.
Strip metadata. Document properties, XMP, author names, embedded attachments.
Apply true redaction, using a tool that removes content rather than covering it, and insert placeholder tokens.
Verify by extraction before the file goes anywhere. Details below.
Translate the redacted file, with tokens marked do-not-translate.
Verify the output the same way, and confirm the token count matches.
Reassociate values only if needed, inside your own environment.
Steps 5 and 7 are the ones people skip, and they are the only steps that produce evidence. For a data room, this whole sequence runs per document rather than per batch — see data room redaction and translation.
Verification Is Extraction, Not Inspection
Opening the redacted file and looking at it proves nothing, because the whole failure class is content that renders invisibly. Verification has to use the same machinery the translation pipeline uses.
Run a text extractor over the redacted file and search the output for every sensitive string, including partials — surname alone, account number without separators, the four-digit year. Unzip the Office container and grep the XML parts directly; it takes one command and catches hidden text, tracked deletions and notes in one pass. For PDFs, check the annotation array and confirm the file has no appended earlier revisions.
Then repeat on the translated output, searching for the same strings plus the placeholder tokens. A token that has vanished means text was dropped; a token that appears in a language other than what you sent means it was translated and can no longer be matched programmatically.
Two greps. They take a minute and they are the entire difference between a redaction you can defend and one you hope is fine.
Sources and Further Reading
Regulation (EU) 2016/679 — GDPR, official text, including data minimisation
Need advice translating scanned PDFs — practitioners on OCR layers, image redaction and what survives a rebuild
Related Reading
Last reviewed 24 August 2026 by the Bluente document engineering team, who build and test the pipeline described here. We update these guides when the underlying standards, regulations or file formats change.
Redact first. Then let the layout survive the language change. Try BluTranslate free.