Redactorr is being built to handle more than clean digital files. The product direction includes scanned pages, photos of paper documents, and handwritten forms.

The important distinction is support level. We only call something supported after it has passed the right gates.

Redactorr's launch-safe path is born-digital files where text can be extracted directly:

• Text-layer PDFs
• Word documents
• Spreadsheets
• CSV and tabular text
• Plain text and UTF-8 text-like files

For these files, detection and redaction run in your browser.

Scanned-page and photo redaction are active product directions.

The app has browser OCR paths for scanned PDFs and direct images, but broad production support is not claimed yet. A scanned document or phone photo can introduce rotation, blur, shadows, perspective distortion, low contrast, and missing text. Those cases need stronger proof before we tell users they can rely on it.

Before scanned pages or photos become fully supported, Redactorr needs to prove:

• OCR can read the target text
• Sensitive values are detected from that OCR text
• Redaction boxes align with the original page or photo
• Exported files do not leak the original values
• The workflow performs reliably on real documents, not only synthetic examples

Handwriting is a separate problem from printed OCR.

Printed OCR can often read typed text in a scan. Handwriting needs handwriting recognition, and messy handwriting can be ambiguous even for people. Redactorr should support handwritten notes and forms eventually, but we will not claim support until a separate handwriting gate exists and passes.

Use this rule:

• If your file has selectable text, it is in the launch-safe path.
• If your file is a scan or photo of printed text, treat it as preview or roadmap until gates pass.
• If your file is handwritten, treat it as a future capability, not current support.

This protects users from assuming a document is safe when the OCR, redaction overlay, or export proof is not complete yet.