Backlog
9Under consideration
Wide tables are silently cut off in exported PDFs
When an item contains a table wider than the printed page, the exported PDF silently loses the columns that overflow the right-hand margin. The customer gets a document that looks complete but isn't, with no warning anywhere. What happens We render items to PDF at A4 with 1cm margins. Chromium shrinks over-wide content to fit up to a bounded factor and then simply clips whatever is left. The clipped text is not drawn on the page and is not in the PDF's text layer, so it cannot be found, redacted, searched or recovered. Real example A delivery-exception report pasted from Excel into Outlook: 14 columns, roughly 1850px wide. The exported PDF prints as far as "Address 2" plus two characters of the postcode. Category, Issue, Repeat, the free-text Comment and Closed are gone from every row. One cell that reads Admin-Mitcham-039-Customer contacted for delivery instructions not followed on 23/01... prints as Admin-Mitcham-0 and stops. Why it matters This is a data-completeness problem on a disclosure product. Items are exported for DSARs and legal disclosure, so handing over a document with content missing is worse than failing loudly — and nothing currently tells anyone it happened. It also produces a confusing second-order effect: a term can be redacted successfully in the interface while no black box ever appears, because the text it matched is not on the page at all. Suggested direction Detect and flag first — cheap, and turns a silent loss into a visible one. At conversion, compare the rendered text against the source and warn on the item when content did not fit. Then remedy — render items that overflow in landscape, or scale the page down further for wide content, so the columns actually print. Raised from support conversation 583, where the missing text was found while investigating a separate export-gate problem (now fixed).
Apply wordlist per file
It’d be great to be able to quickly apply word list redaction on a per mail/file basis. As we’re processing large mailboxes, the PDFs have not been rendered for most items, so we are having to do them one at a time.
Filter from a selected item (right-click “See all from this sender / tag / date”)
Add a quick way — e.g. a right-click context menu on an item — to filter the list by an attribute of the currently selected item, without typing it out manually. "See all items from xyz@abc.com" — applies a From filter using the selected item's sender. "See all items with tag 'sent'" — applies a tag filter. "See all items received on 20/08/2025" — applies a date filter. Reported via support as a faster way to pivot from one item to everything related to it.
Manually choose which copy to keep per duplicate group
Today the kept "Original" in each duplicate group is chosen by a global strategy (Settings → Duplicates → Smart pick / Keep newest / Keep oldest), which re-picks across all groups. There is no way to hand-pick a specific copy for an individual group. Request: a per-group control to select which copy is the authoritative one (override the auto-pick for that group), so reviewers can correct cases where the algorithm kept the wrong copy. Raised while reviewing ~2,600 duplicates across a large multi-mailbox import.
Side-by-side comparison of duplicate copies before resolving
When deciding which copy of a duplicate to keep, copies can currently only be previewed one at a time. Request: a side-by-side / compare view — e.g. the currently-chosen copy on the left, and the ability to flick through the other copies on the right, choosing which to keep from there. Would make reviewing large duplicate sets far faster and more confident.
Browsable folder tree for imported mailboxes (Inbox / Sent / sub-folders)
Surface the original mailbox folder structure as a navigable tree in the project view, so each mailbox can be explored by its folders (Inbox, Sent, Deleted, Archive and custom sub-folders) separately rather than as one flat list. The folder path is already captured per email on import, so this is primarily a UI/navigation feature. Raised while reviewing a large multi-mailbox eDiscovery import (~15.8k emails across 20 PST parts).
Handle very large emails (>5 MB) in PDF conversion
A small number of emails carry pathologically large HTML bodies (e.g. 5–7 MB — usually huge embedded/inline content). The PDF renderer (Puppeteer) times out on these even after retries, so they end up pdf_status='failed' and the file finishes as partial rather than completed. Observed in production on a 1,143-email mailbox: 1,141 converted fine, 2 emails (~5 MB and ~7 MB HTML) timed out. This is a pre-existing pdf-service limit, surfaced now that conversion runs on the durable worker and reports status honestly. Options to explore: Strip/normalise more aggressively before render (we already strip oversized base64 image data-URIs; extend to other large inline content). Raise the per-email render timeout for known-large payloads, or render large emails on a dedicated slower path. Fall back to a simplified/text-only PDF for emails that exceed a size threshold instead of failing them. Goal: a huge email should still produce a PDF (even a simplified one) so files reach completed, not partial.
Keep Gmail labels and Outlook categories when you upload
If you've tagged your emails in Gmail (labels) or Outlook (categories), those tags get lost when you upload to RedactBox today. You see the subjects, senders, and dates — but not the way you'd organised the data in the first place. This feature would: Keep your Gmail labels when you upload a mbox file Keep your Outlook categories when you upload a PST file Let you add your own tags to emails inside RedactBox — one at a time or in bulk Filter the email list by tag, so you can work through one category at a time Include tags in exports so the document chain is preserved Particularly useful if you're handling a Subject Access Request and the relevant emails are already labelled "Client A" or "HR" — you'd be able to scope your redactions straight to that label rather than searching through everything.
OCR Scanning of PDFs
Where documents are flattened. Scan using OCR and enable those documents to be included in text search and highlighted for redaction.
Next up
1Committed and queued
In Progress
Actively being built
No In Progress issues
Done
49Recently shipped
Search to Redact Functionality
Being unable to search for specific keywords or specific emails was really problematic. I ended up exporting things back into outlook, deleting and sorting email chains and reimporting - which was time consuming.
The ability to share Projects
Allows you to share projects with other users on the platform.
Import common document attachments as PDFs (convert Office docs)
When an email has an attachment that's a common document type — Word (.doc/.docx), Excel (.xls/.xlsx), PowerPoint (.ppt/.pptx), and similar — let the user import it into the project as a redactable PDF. We already support importing PDF attachments directly into a project. The gap is the non-PDF document types: they'd need to be converted to PDF on import (a conversion step we don't have yet) before they can enter the redaction workflow. Goal: bring more attachment content into redaction — a user shouldn't have to download a Word/Excel attachment, convert it elsewhere, and re-upload it. Pick it from the attachment, we convert + import it as a PDF document in the project. Notes / scope: Reuse the existing 'import attachment as document' flow; add a convert-to-PDF stage for supported non-PDF types. Decide the supported set (Office formats first; maybe images, .rtf, .txt, .eml later). Conversion likely belongs on the worker / a conversion service (LibreOffice headless or similar) — needs design.
Upload Attachments from Emails
Grab attachments from emails, convert to PDF and then allow to redact.
Never-redact list: protect specific names from every redaction pass
A list of names, addresses or terms that must never be redacted, regardless of what a word list, Auto-Redact or Search & Redact would otherwise match. Why The requester's own name has to survive redaction, and so do things like the organisation's name or a case reference. Today a broad word list or Auto-Redact can catch them, and the only fix is to spot it and remove the redaction by hand — on every item. The ask A project-level "never redact" list that every redaction method respects. Simpler and independent of automatic name discovery, and useful on its own. Asked twice in support ("How do I use a whitelist of names that should not be redacted ever?" and "How do I whitelist certain names and email addresses which I don't want to redact?"). Logged from conversations 67 and 66.
Blank Pages at the beginning of PDF Exports
Fixed and deployed. Blank pages at the start of an exported PDF were caused by how documents authored in Word/Outlook declare their page layout: it forced a page break that left the document header alone on the first page, with the content pushed onto the next page (and, for multi-section messages such as bounce notifications, over several pages). The exporter no longer honours that author-supplied page layout, so the header and content now start together on page one. Genuine, deliberate page breaks are still respected. Note: this applies to documents processed from now on. PDFs that were already exported keep their existing layout — re-exporting the affected documents produces the corrected version.
[bug] Password protected PDF attachments cause locked out display
When a PDF attachment is password protected, the page prompts you for a password. When this is cancelled, it just prompts again, soft locking the page until you refresh.
Redaction Word Lists
I'd find it incredibly useful to be able to upload a list of pre-defined names, ideally via a CSV file, for the Search to Redact functionality. This would allow me to efficiently redact multiple specific names across documents, saving significant time compared to manually entering each name individually.
Embedded Image Redaction
Redact text and other content within images.
Add Header vs Body Filtering to Email Filter
This would be incredibly useful for our SAR triage process. We need more refined filtering options, like filtering on header vs. body, to effectively narrow down entire mailboxes and identify relevant emails before the redaction stage.