SafeRedact
Documentation

Supported files and formats

What processes, how each format is handled, and where the edges are. Check here before uploading an export.

Documents and text

This page is the authoritative list of what SafeRedact processes, how each format is handled, and where the edges are. When in doubt about an export, check here before uploading.

PDF, DOCX, XLSX, TXT, HTML, CSV, and JSON are processed directly. Text is extracted, detections run against it, and the redacted output is rendered to PDF, with structured formats also reflected in the reports.

Word and Excel files are also returned in their own format, with the layout intact and the reviewed text redacted in place. Only content that was shown for review is kept: the document body, tables and text boxes in Word, and the cell values of every worksheet in Excel. Layers the reviewer never saw are removed from the returned file rather than passed through unexamined: tracked changes (deletions are dropped, insertions kept), comments, footnotes and endnotes, headers and footers, images and embedded objects, hyperlink targets, field codes, formulas (the calculated value stays), and document properties. If the app cannot verify that the rewritten file matches the reviewed redaction exactly, it returns the redacted text as a .txt file instead, alongside the PDF rendering.

Scanned or image-only PDFs are the main caveat: a PDF with no text layer yields no text to scan. The confidence dashboard flags zero-detection files during review for exactly this reason; treat a flagged scan as unreviewed content and handle it separately.

Email

EML files are processed as full MIME messages: headers, recipients, body, and attachments, with each attachment routed through the matching extractor above. This is the format PST extraction produces internally, and it has the deepest coverage.

PST is the recommended export format for mailboxes. Each PST is unpacked in the browser: every message becomes an EML, and attachments are carried across and scanned, including messages embedded inside messages. Attachment handling has defined limits (up to 20 attachments per message, 25MB per attachment), and anything beyond a limit is marked with an explicit placeholder rather than dropped without trace. In Microsoft Purview, set the PST package size to 1GB or 2GB; large mailboxes then split across packages automatically, and the app enforces a 2GB per-file ceiling with instructions if an oversized package arrives.

MSG files process with an important limitation: message bodies, headers, and recipients are detected, but attachment content inside a .msg is not examined. If a mailbox was already exported as .msg, the messages themselves still process; treat attachments as unreviewed, and either re-export that mailbox as PST or collect the attachments separately and upload them alongside.

Chat exports

Slack exports are read as conversations. Add the export ZIP as Slack provides it, or the unpacked folder's files. A workspace export keeps one JSON file per channel per day, and each becomes a transcript, one message per line with the time, the author's name and the text, with mentions, links, thread replies, shared file names and app messages written out in plain words. An export of one person's channels and conversations keeps one JSON file per conversation instead, and each becomes one transcript with a heading for every day. Names come from the export's own users.json (org_users.json in an Enterprise organisation export), so a message's author and the people it mentions read the same way in every channel; when that file is missing, names are taken from the messages themselves. The transcript is what the reviewer sees and what the pack carries, redacted, under the export's own folders. The workspace files at the root of the export (users.json, channels.json and the like) name people for the transcripts and are not added as documents. The TXT variant of a single person's export is processed as plain text files.

An export is the whole workspace, and an access request concerns one person. When a data subject has been entered, SafeRedact asks, once per export, whether to keep only the channel-days that carry that person (the days they wrote on, are named on or are in a thread on, and any direct messages with them) or every day. The decision is made per day, never per message, and a kept day is kept whole. The days left out are counted per channel in the activity log and in the pack’s internal audit, and every kept transcript states the rule under its heading. Within a kept day, every message is kept.

Containers

ZIP packages, including Purview’s SharePoint and OneDrive collections, are unpacked and their contents routed by type. Unsupported entries inside a container are not processed; the pack’s coverage information notes them so they can be handled deliberately. A Purview collection routinely includes image files, which fall under the next heading.

Not processed

Images (standalone JPG, PNG, TIF) are not processed, whether uploaded directly or found inside a container. To find them in a Purview export, filter the export’s Items report by file extension, then handle them outside SafeRedact.

Video and audio are out of scope entirely. CCTV, bodycam, and call-recording redaction is a separate tool category; if a request spans documents and footage, plan for two tools from the start.

Checking an export before you start

Purview’s Items report lists every exported item with its type. Two minutes filtering it answers the questions that matter: how many items are in formats above, whether image files are present, and whether partially indexed items were included in the export. Partially indexed items are excluded by default and must be opted in at export time; they are also disproportionately the scanned and encrypted material a DSAR needs deliberate decisions about. The Purview export guide covers the export-time settings themselves.