redactor
A PDF redaction library and CLI tool with secure text removal using MuPDF. Redacts Verizon bills so you can expense them without leaking your call metadata.
Use Case
Originally built for redacting Verizon phone bills before submitting them to employer expense reimbursement systems like Concur or Expensify.
When submitting phone bills for work expense reimbursement, you typically need to:
- ✅ Keep the billing amounts visible (for verification)
- ❌ Remove your account number (privacy/security)
- ❌ Remove personal phone numbers (privacy)
- ❌ Remove call detail information (times, locations, destinations)
- ❌ Remove other personal contact information
This tool ensures your sensitive information is physically removed from the PDF (not just blacked out), so it cannot be extracted by the expense system or anyone who views the document.
Perfect for freelancers, remote workers, and employees who need to submit redacted bills for work expenses while maintaining privacy.
Features
- Secure Redaction: Physically removes text from PDFs (not just visual overlay)
- Type3 Font Support: Handles complex PDF encodings via MuPDF
- Phone Number Detection: Automatic NANP phone number redaction
- Verizon Account Numbers: Specialized detection for 9-5 format accounts
- Call Detail Redaction: Automatically redacts time, origination, and destination columns
- Pattern Matching: Literal strings and powerful regex patterns
- Regex Support: Full regular expression support for custom patterns (SSNs, emails, IPs, URLs, etc.)
- CLI & Library: Use as a command-line tool or Rust library
Installation
As a CLI Tool
As a Library
Add to your Cargo.toml:
[]
= "0.2"
Quick Start
CLI Usage
Redact Verizon Bill for Expense Report
# Redact account number, phone numbers, and call details (recommended for expense reports)
This command will:
- Find and remove your Verizon account number (e.g.,
123456789-00001) - Remove all phone numbers from the document
- Remove call detail information (times like "10:26 PM", locations, destinations)
- Preserve billing amounts and other expense-relevant information
Other Common Uses
# Redact only phone numbers
# Redact custom patterns (e.g., email addresses)
# Extract text to verify what's in the PDF
Library Usage
use ;
use Path;
Security
This library uses MuPDF's built-in redaction system to physically remove text from PDFs, making it unextractable. This is more secure than visual-only redaction methods that just draw black boxes over text.
Why This Matters for Expense Reports
Many expense systems (Concur, Expensify, etc.) can extract text from PDFs for automated processing. Simple "black box" redaction doesn't actually remove the text - it's still embedded in the PDF and can be extracted. This tool ensures your account numbers and personal phone numbers are truly gone before you submit to your employer.
Verification
# After redaction, verify text is gone
# Your account number and phone numbers should NOT appear in output
Supported Patterns
Built-in Detectors
Phone Numbers (NANP)
(555) 123-4567555-987-6543555.111.2222+1 555 234 5678
Verizon Accounts
123456789-00001(9-5 format)12345678900001(14 digits)- Context-aware detection
Custom Patterns
Literal Strings
- Exact text matching
- Case-sensitive by default
- Multiple patterns supported
Regular Expressions
Full regex support for custom pattern matching:
// Social Security Numbers
Regex
// Email Addresses
Regex
// IP Addresses
Regex
// URLs
Regex
// Credit Cards
Regex
// Custom ID formats
Regex
// Case-insensitive patterns
Regex
Features:
- Full Rust regex syntax support
- Pattern validation with clear error messages
- Case-insensitive matching (
(?i)flag) - Combine multiple regex patterns
- Mix regex with built-in detectors
Important Notes:
- Word boundaries (
\b) may not work reliably due to PDF text extraction - Use patterns without word boundaries for best results
- Example: Use
\d{3}-\d{2}-\d{4}instead of\b\d{3}-\d{2}-\d{4}\b
Regex Pattern Guide
The library provides full regular expression support for custom pattern matching, powered by Rust's regex crate. Patterns are validated before processing.
Common Pattern Examples
use ;
let service = with_secure_strategy;
// Social Security Numbers (XXX-XX-XXXX)
Regex
// Email Addresses
Regex
// Phone Numbers (custom format)
Regex
// IP Addresses
Regex
// Credit Card Numbers
Regex
// URLs (http/https)
Regex
// Currency Amounts
Regex
// Dates (YYYY-MM-DD)
Regex
// Custom IDs (e.g., AB123456)
Regex
// Case-insensitive matching
Regex
Important Considerations
Word Boundaries
PDF text extraction often concatenates text without spaces, making \b word boundaries unreliable:
- ❌ May not work:
\b\d{3}-\d{2}-\d{4}\b - ✅ Better:
\d{3}-\d{2}-\d{4}
Error Handling Invalid regex patterns return clear error messages:
let result = service.redact;
// Error: "Invalid regex pattern: ..."
Performance
- Regex compilation happens once per pattern
- Text extraction occurs once per regex target
- Efficient pattern matching using Rust's optimized regex engine
- Respects
max_hitslimit to prevent performance issues
Testing Regex Patterns
The library includes 22+ integration tests covering basic pattern matching, multiple patterns, case-insensitive patterns, invalid patterns (error handling), no matches (graceful handling), combining regex with built-in detectors, and edge cases.
Run regex pattern tests:
Command Reference
Default Mode: Redaction
)
Extract Subcommand
)
Examples
Expense Report Workflow
# 1. Download your Verizon bill (e.g., January-2026.pdf)
# 2. Redact sensitive information
# 3. (Optional) Verify redaction by extracting text
# Your account number and phone numbers should NOT appear in the output
# 4. Upload January-2026-redacted.pdf to Concur/Expensify
Redact Multiple Pattern Types
# Combine built-in detectors with literal patterns
Redact with Regex Patterns
# Redact email addresses
# Redact Social Security Numbers
# Combine regex with built-in detectors
Library: Custom Redaction Strategy
use ;
let service = new;
service.redact?;
Library: Pattern Matching
use ;
let matcher = new;
let phones = matcher.extract_all;
// phones: ["(555) 234-5678", "555-987-6543"]
Library: Regex Pattern Redaction
use ;
use Path;
let service = with_secure_strategy;
// Redact Social Security Numbers
service.redact?;
// Multiple regex patterns
service.redact?;
// Combine regex with built-in detectors
service.redact?;
Performance
- Unit tests: <0.1s (15+ tests)
- Integration tests: ~0.5s (10+ tests including regex patterns)
- Full test suite: <2s (50+ tests)
- Redaction: ~50-80ms per page (typical)
- Regex compilation: <1ms per pattern (cached during operation)
Architecture
redactor/
├── src/
│ ├── domain/ # Business logic (phone, account detection)
│ ├── redaction/ # Redaction strategies (secure, visual)
│ ├── error.rs # Custom error types
│ ├── lib.rs # Library API
│ └── main.rs # CLI application
└── tests/
├── common/ # Shared test utilities
├── unit/ # Fast unit tests
├── integration_test.rs
└── cli_integration_test.rs
Development
Prerequisites
- Rust 1.70+
- MuPDF development libraries
Building
Testing
The test suite is organized into unit, integration, and end-to-end layers, each serving a distinct purpose.
Running Tests
# All tests
# Unit tests only (fastest)
# Integration tests
# CLI/E2E tests
# Regex pattern tests
# Specific test
# With output
# Advanced options
Test Structure
tests/
├── common/ # Shared utilities
│ ├── assertions.rs # Custom assertions
│ ├── fixtures.rs # Test PDF builders
│ └── pdf_helpers.rs # PDF inspection utilities
├── unit/ # Fast unit tests
│ ├── domain_tests.rs # Business logic tests
│ └── pattern_tests.rs # Regex/pattern tests
├── integration_test.rs # Integration tests
└── cli_integration_test.rs # CLI/E2E tests
Writing Tests
Unit Test Example
// tests/unit/domain_tests.rs
use PhoneNumberMatcher;
Integration Test Example
// tests/integration_test.rs
use *;
use ;
use TempDir;
Test Utilities
The test suite includes shared utilities in tests/common/:
Custom Assertions
use *;
assert_redacted;
assert_preserved;
assert_valid_pdf;
assert_all_redacted;
Test Fixtures
use *;
// Builder pattern for test PDFs
new
.with_title
.with_verizon_account
.with_phone
.with_content
.build?;
PDF Helpers
use *;
let text = extract_text?;
let count = count_pattern_in_pdf?;
let phone_count = count_phones_in_pdf?;
let has_pattern = pdf_contains_any?;
Test Coverage
The suite covers:
- Phone number detection (NANP formats, edge cases)
- Verizon account detection (9-5 format, 14-digit format)
- Pattern matching (literal strings, regex)
- Secure redaction (physical text removal verification)
- Combined redaction (multiple targets simultaneously)
- Error handling (missing files, invalid PDFs, corrupted PDFs)
- CLI interface (end-to-end workflows)
Troubleshooting
Tests fail to compile:
Test PDFs not found:
Slow test execution:
Code Coverage
Code coverage is tracked using cargo-llvm-cov. Reports are automatically generated on every PR and push to main.
# Install cargo-llvm-cov
# Generate coverage report (terminal output)
# Generate HTML report
# Generate LCOV report (for CI/Codecov)
Alternative: Tarpaulin
# Install tarpaulin
# Run coverage
# View report
Coverage Status:
- 199+ passing tests across unit, integration, property-based, CLI, and edge case categories
- Estimated coverage: ~95%
Mutation Testing
Mutation testing complements code coverage by validating test quality. It systematically introduces small bugs (mutations) into the source code and verifies that tests detect them. While coverage shows what code is executed, mutation testing reveals whether tests actually validate behavior.
# Install cargo-mutants
# Run mutation testing (5-15 minutes)
# Generate HTML report
How it works:
- Mutations are introduced (operator changes, logic flips, return value modifications)
- Tests run against each mutation
- Results are classified: killed (good), survived (needs attention), timeout, or build failure
- Mutation score calculated:
killed / (killed + survived) × 100%
Target metrics:
- Mutation score >85% indicates strong test quality
- Surviving mutations highlight areas needing stronger test coverage
- Weekly runs via GitHub Actions with reports uploaded as artifacts
Configuration:
Mutation testing is configured via mutants.toml in the project root, which excludes test code, FFI bindings, and CLI entry points from mutation.
Benchmarks
Benchmarks measure performance of critical operations using the Criterion framework.
# Install criterion (if not already installed)
# Run all benchmarks
# Run specific benchmark
# Generate HTML report
Creating Benchmarks
Create benchmarks in benches/ directory:
// benches/redaction_benchmarks.rs
use ;
use PhoneNumberMatcher;
criterion_group!;
criterion_main!;
Performance Targets
| Operation | Target | Typical |
|---|---|---|
| Phone detection (small text) | <5µs | ~1-2µs |
| Account detection | <10µs | ~5µs |
| Pattern variant generation | <1µs | ~0.5µs |
| PDF text extraction (1 page) | <50ms | ~20-30ms |
| Secure redaction (1 page) | <100ms | ~50-80ms |
Linting
Limitations
- Requires MuPDF system libraries
- Best results with standard PDF fonts
- Complex annotations may require additional handling
- Scanned PDFs (images) require OCR preprocessing
Contributing
Contributions are welcome. To get started:
- Fork the repository
- Create a feature branch
- Add tests for new functionality
- Ensure all tests pass
- Submit a pull request
Adding Tests
When adding new functionality:
- Determine the appropriate test layer (unit/integration/e2e)
- Use existing utilities from
tests/common/ - Follow the naming convention:
test_<feature>_<scenario> - Include error case testing
- Ensure tests are isolated and deterministic
Test Guidelines:
- Keep unit tests fast (<1ms per test)
- Maintain isolation (no shared state between tests)
- Ensure determinism (same result every time)
- Use clear, descriptive test names
- Leverage shared utilities to avoid duplication
License
MIT License - see LICENSE-MIT for details.
Acknowledgments
- MuPDF for PDF processing
- lopdf for PDF manipulation
- pdf-extract for text extraction
Security Notice
This tool is designed for legitimate redaction purposes. Users are responsible for verifying redaction completeness, complying with applicable laws and regulations, testing output before distribution, and understanding PDF structure limitations.
Always verify redacted PDFs before sharing sensitive documents.