Skip to content Omitly is launching soon — join the waitlist →

Technical trust page · product behaviour as at v1.0.0, verified 5 July 2026

How Omitly redacts

Redaction is removal, not concealment. This page explains — in the vocabulary of the PDF standard itself — what Omitly does to a document, why the common approaches fail, and how you can independently verify both.

The failure mode we exist to eliminate

A PDF is defined by ISO 32000-2, the international standard for the Portable Document Format. Under that standard, a document is not a picture of a page: it is a graph of first-class objects — content streams containing the text and graphics operators, fonts, images, annotations, form fields, embedded files, metadata streams, and a cross-reference structure that ties them together.

The critical detail for redaction is that an annotation and the text beneath it are separate objects. A black rectangle drawn with a markup, comment or shape tool is an annotation layered over the content stream. The text it covers remains fully intact in the file. Anyone can select it, copy it, extract it programmatically, or simply delete the annotation. This single misunderstanding is the most common root cause of the high-profile redaction failures of the past 20 years — from the 2005 Calipari report to the 2019 Manafort filings.

Two further properties of the format compound the problem:

Incremental saves. ISO 32000 permits updates to be appended to the end of a file rather than rewriting it. A document “edited” this way retains its complete prior versions — including content the author believed was deleted.

Metadata and ancillary streams. XMP metadata packets, the document information dictionary, embedded file attachments, OCR text layers beneath scanned images, and unreferenced (orphaned) objects can all carry sensitive content invisible in any viewer.

Visual inspection cannot detect any of this. A document can look perfectly redacted and be perfectly recoverable.

What Omitly does

Omitly performs true content removal at the object level of the ISO 32000 model, followed by structural sanitisation and independent verification. In sequence:

1. Content-stream rewriting. Redacted regions are removed from the content streams themselves — the text-showing and graphics operators for the selected content are deleted, not painted over. There is no overlay, no annotation, and no “hidden” layer; the black bar you see is a visual marker drawn after the data is already gone, and it is optional. Where a redaction region covers part of an image, the covered pixels are overwritten in place in the decoded image data; an image Omitly cannot scrub with confidence (unusual colour spaces, masks, exotic compression) is removed in its entirety rather than partially cleaned. Anything the engine cannot provably cover — inline images, for example — is flagged, and the operation reports failure rather than passing silently.

2. Structural sanitisation. The output is written as a fully rewritten document — a single revision with no incremental-update history. Orphaned objects are dropped. XMP metadata, the document information dictionary and application PieceInfo data are removed outright, and OCR/text layers within redacted regions are deleted by the same content-stream rewriting as visible text. Two scope limits, stated plainly: pre-existing embedded file attachments and document JavaScript are not currently removed; and form-field content is handled by detection, not deletion — a form-field appearance stream under a redaction region causes the operation to report failure rather than claim a clean result. The governing principle is default-deny: no path Omitly cannot prove clean is ever reported as redacted.

3. Verification pass. Before Omitly reports success, it independently re-parses the output file and checks every redacted region two ways: geometrically (no text or image renders into the region) and at the byte level (the removed content does not appear anywhere in the decompressed file). A region passes only if both checks hold. This check is also available standalone: our free leak checker can audit any “redacted” PDF — including ones produced by other tools — and report whether sensitive text survives beneath the redactions. It runs entirely in your browser; nothing is uploaded.

4. Tamper-evident proof. Every redaction operation embeds an audit report in the output and seals the result: an Ed25519 signature over the whole delivered file (with SHA-256 content hashes), verified by recomputation over the exact bytes the holder presents — one changed byte fails it. The seal is an integrity mechanism, not an identity one: the signing key is generated per install, so a valid seal proves the document has not been altered since sealing, and the signer key fingerprint is surfaced for out-of-band comparison — it does not by itself prove who produced the file. The certificate records when the operation ran as reported by the device clock; it is not independently timestamped. (If you add the optional digital signature, an RFC 3161 timestamp from a timestamp authority of your choice can be included; only a hash of the document is sent.) The precise scope of what the seal does and does not warrant is documented in our public threat model.

Omitly produces a tamper-evident certificate that the redacted content is not present in the output document and that the document has not been altered since. This is a technical artifact about a single output file. It is not proof that the information has been destroyed across your other records, drafts, email, or backups, and it is not a determination that you have met any specific legal obligation — that remains your responsibility and, where relevant, your lawyer's.

What Omitly deliberately does not do

Your documents never leave your device. Omitly is local-first by architecture, not by policy: redaction, verification, licence validation and certificate generation all execute on-device, and there is no server-side processing of document content. The app makes exactly three kinds of outbound request, none of which carries document data: it fetches a signed release manifest to check for updates; if you use the in-app support form, it sends the message you typed plus the app version and OS string; and if you opt in to a timestamp while digitally signing, it sends a hash — never the document — to the timestamp authority you configure. There is no telemetry. For a due-diligence questionnaire, that keeps the data-flow answer short: no third-party processor handles document content, which is designed to simplify the data-residency and confidentiality analysis your firm has to make for privileged or AML/CTF-relevant material.

We do not warrant outcomes we cannot see. The certificate attests to process integrity: that the specified regions were removed by the specified pipeline and that the delivered file is intact. It does not — and no tool honestly can — warrant that a human selected the right regions. Selecting what to redact remains professional judgment; producing tamper-evident evidence that it is absent from the delivered file is ours.

What ships today

The table below doubles as a cryptography inventory for vendor assessments; the full machine-readable version lives on our security portal.

Domain Standard / mechanism
Document format ISO 32000-2 (PDF 2.0) object model; true content-stream removal — operators deleted, never overlaid.
Output structure Single-revision full rewrite (incremental-update history collapsed); orphaned objects dropped; XMP metadata and the document information dictionary removed.
Tamper-evidence seal Ed25519 signature over the whole delivered file, with SHA-256 content hashes; strict signature verification; verified by recomputation over the bytes you actually hold.
Optional digital signature PDF (CMS) signature with your own certificate; optional RFC 3161 timestamp; NIST SP 800-131A algorithm floors (SHA-1-issued certificates and RSA under 2048 bits are refused), re-checked at every signing. No CA trust-chain or revocation (OCSP/CRL) checking in this release — the signer name is read from the certificate and is self-asserted.
Supply-chain transparency CycloneDX SBOM plus a cryptographic bill of materials (CBOM), generated in CI for every build.

On the roadmap, and deliberately not claimed above until they ship: a post-quantum hybrid seal (documented target: Ed25519 + SLH-DSA, FIPS 205), PAdES B-LT signature longevity, and a signed per-release attestation binding artifact hashes and the SBOM/CBOM, published at security.omitly.app/releases.

Verify it yourself

We encourage exactly the scepticism this page describes. Take any document Omitly has redacted and: open it in a different viewer and attempt to select or copy text in redacted regions; extract text programmatically (pdftotext, qpdf --qdf, or your tool of choice); inspect the file for incremental updates and orphaned objects; run it through our leak checker — or anyone else's; and validate the seal with the free omitly verify command, as described on how verification works. Our security portal publishes the threat model, cryptography inventory and disclosure policy this page summarises.

If you find something that survives a redaction, we want to know: responsible disclosure (also in security.txt).

Redaction you can prove

Object-level removal, an independent verification pass, and a seal anyone can check offline — on your device, not ours.

Last updated 5 July 2026. Product behaviour described as at v1.0.0; the fact-check ledger for this page is maintained alongside the site source. Think we've got something wrong — a claim, a mechanism, a standard reference? Tell us and we'll correct it. This page describes how the software behaves; it is general information, not legal advice.