Understanding Redacted Items
How Redactorr replaces sensitive data with reversible placeholders
Redacted Items: Name Tags for Your Secrets
When Redactorr finds sensitive data, it doesn't just delete it or replace it with "XXXXXX". Instead, it creates a redacted item - a smart placeholder that can be reversed later.
Think of redacted items like name tags at a coat check. You hand over your coat (sensitive data), and they give you a ticket (redacted item). Later, you can exchange the ticket to get your exact coat back.
What Redacted Items Look Like
Redacted items follow a simple pattern:
For example:
- [EMAIL_1] - The first email address found
- [PHONE_2] - The second phone number
- [SSN_1] - A Social Security Number
- [API_KEY_3] - The third API key detected
Why Redacted Items Matter
1. They're Reversible If you need the original data back, you can "restore" it using the redaction map. This is the right approach when you need to share redacted data temporarily but restore it later.
2. They Preserve Context Instead of replacing "[email protected]" with random gibberish, [EMAIL_1] makes it clear that there was an email address there. You can still follow the logic of the document.
3. They're Deterministic The same input always produces the same redacted items. If "[email protected]" appears five times in your document, it becomes [EMAIL_1] all five times. This preserves relationships in your data.
4. They're Human-Readable [EMAIL_1] is much easier to work with than something like "8f3b9a2c-4d7e-1f8a-9b2d-5c6e8a9f3b2c". You can reason about the data even when it's redacted.
Redacted Item Types
Each category of sensitive data gets its own prefix:
| Data Type | Placeholder Format | Example |
|---|---|---|
| [EMAIL_N] | [EMAIL_1] | |
| Phone | [PHONE_N] | [PHONE_2] |
| SSN | [SSN_N] | [SSN_1] |
| Credit Card | [CARD_N] | [CARD_1] |
| API Key | [API_KEY_N] | [API_KEY_3] |
| Address | [ADDRESS_N] | [ADDRESS_1] |
| Name | [NAME_N] | [NAME_5] |
How Restoration Works
When you redact a document, Redactorr creates a redaction map - a secure lookup table that links redacted items back to original values:
This map is:
- Stored locally in your browser (IndexedDB)
- Handled as browser-side review state during redaction
- Encrypted if you use Secure Share
- Ephemeral - deleted when your session ends (unless saved)
To restore, you paste the redacted text back into Redactorr, and it swaps the redacted items back for the original values.
Use Cases
Sharing with External Teams Send a redacted document to a contractor. When the project is done, restore the original internally.
Testing and QA Test your app with redacted production data. Restore specific records when debugging issues.
Compliance and Auditing Archive redacted logs for compliance. If an audit requires details, restore specific entries.
Collaborative Review Share a document for feedback without exposing PII. Restore after approval.
Redaction Map Security
If you're worried about the redaction map being a risk:
It's local-only - Stays local during detection and redaction unless you choose a later workflow
It can be encrypted - Use Secure Share to encrypt the map with a password
It's not required - You can delete the map and treat redaction as one-way
It has no keys - The map only has value if someone also has the redacted document
Bottom line: The redaction map is as secure as your browser's local storage.
Need help?