Redacting Personal Data and Secrets: Removing What Should Never Have Been Shared

Documents shared outside an organisation routinely contain information that should not leave it: names, addresses, phone numbers, identification numbers, and, more dangerously, passwords, API keys, and tokens that were pasted into a document by mistake. Redaction is the process of removing that information before sharing, and it is one of those tasks where a superficial job is worse than no job, because a document that looks redacted invites trust while still leaking. The PII and Secret Redactor identifies personal data and secret-like patterns in text you supply and produces a redacted version. It processes the text you supply in the browser; do not paste real secrets or production tokens into any redactor or external tool, because the act of pasting itself can expose them, and a secret that has been pasted outside its owning system should be revoked and replaced, not merely redacted from a copy.

The first distinction is between personal data and secrets, because they demand different handling. Personal data, such as a name combined with an address or an identification number, is sensitive because it identifies a person, and its disclosure can harm that person even when no system is compromised. Secrets, such as a password or an API key, are sensitive because they grant access, and their disclosure can compromise a system even when no person is identified. A redactor should handle both, but the response to a leak differs: personal data exposure calls for notification and minimisation, while secret exposure calls for immediate revocation, because a redacted copy does not un-expose the original.

How it works

A redactor scans text for patterns: email addresses, phone numbers, identification numbers, and the characteristic shapes of API keys and tokens, such as long strings of mixed characters with a recognisable prefix. It replaces each match with a placeholder, and a careful redactor also reports what it found and where, so the user can review the result rather than trusting it blindly. Pattern matching has limits: it catches formats it knows, and it misses personal data that does not follow a pattern, such as a name in free prose, which is why a redactor's output always needs a human review pass, especially for names, job titles, and other context-dependent identifiers.

How it works

The critical technical point is that true redaction removes the underlying text, not merely covers it. In a PDF, drawing a black rectangle over text leaves the text in the file, recoverable by anyone who copies it or removes the rectangle, and several public incidents have resulted from exactly that mistake. In a document, changing the font colour to match the background leaves the text equally recoverable. A proper redactor replaces the characters themselves, and the verification step is to extract the text from the redacted file and search it for the removed values: if the value is found anywhere, the redaction failed, however clean the document looks on screen.

Worked example

Worked example with sample values. Suppose a sample document of 800 words contains 12 items to redact: 4 email addresses, 3 phone numbers, 2 identification numbers, and 3 secret-like strings, which sum to 12 items. The redactor flags 11 of them automatically and misses 1 name written in prose, which the human reviewer catches, giving 11 automatic detections out of 12 items, or about 92 percent automatic coverage, and 12 out of 12 after review, or 100 percent. Verification then extracts the redacted text and searches for all 12 original values, finding 0 of them, which confirms the redaction. The 1 missed item is the lesson: automatic coverage in the nineties is good, but the review pass is what reaches 100 percent, and skipping it leaves a leak. These are sample values for illustration, using sample data only, never real personal data or secrets.

Worked example

The same example shows the secret-handling difference. Suppose one of the 3 secret-like strings is a sample API key that resembles a production key format. Redacting it from the document is necessary but not sufficient: if that key, or a real key like it, was ever shared in an earlier version of the document, it must be revoked, because redacting later copies does not withdraw the access the key grants. The count to remember is simple: personal data is protected by removing it from future copies, while a secret is protected only by revoking it at the source, and confusing those two responses is how leaked credentials stay valid long after the document that leaked them has been cleaned.

Mistakes to avoid

One common mistake is redacting with black boxes over text in a PDF, as described above, which is not redaction at all. Another is redacting only the visible copy while leaving the original in version history, comments, tracked changes, or metadata, where it remains accessible to anyone with the file. A third is using a placeholder that reveals the length or the format of the removed value, which can help an attacker guess it; a uniform placeholder such as [REDACTED] reveals nothing. Check the whole file, including metadata and history, not just the rendered page.

Mistakes to avoid

A further mistake is pasting a real document containing real secrets into an online redactor in the first place. Even a tool that runs in the browser may transmit or log its input, and the safe workflow is to redact inside the owning system, or to work on a sanitised copy with sample values standing in for the real ones, and to treat any real secret that has left the system as exposed. Also avoid the temptation to redact and then share widely without review: the review pass, the text-extraction verification, and the metadata check are part of the job, not optional extras, and each of them has caught leaks that the others missed.

Putting it into practice

Build redaction into the sharing routine: scan the document, review the flagged items, add the context-dependent items the scanner missed, replace the underlying text rather than covering it, verify by extracting and searching the redacted text, and check metadata and version history. For secrets, revoke at the source in parallel, because no amount of document cleaning substitutes for revocation. Keep a short checklist of the patterns that matter for your documents, and re-check it whenever a new document type is shared, because each new format brings new places for sensitive data to hide.

Related tools and reading: Related tools and reading: the EXIF Privacy Remover and the Client-Side Secret Exposure Checker cover neighbouring needs that pair naturally with this one, and the guide at [/blog/exif-privacy-remover-guide/] extends the same topic with further background and examples for readers who want to go deeper.

Key points

• True redaction removes the underlying text, not just covers it visually
• Pattern matching catches formats it knows, so a human review pass is essential
• Check metadata, comments and version history, not only the visible page
• A leaked secret must be revoked at the source, not merely redacted from copies

In short: t.rue redaction removes the underlying text, not just covers it visually

One habit ties all of this together: re-check after every change. A result is only as current as the input it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.