Scan a PDF on-device and return candidate regions that look like PII — emails, US SSNs, phone numbers, card numbers, and Australian identifiers (TFN, ABN, ACN, Medicare, Centrelink CRN, IHI, BSB; kinds 'tfn'/'abn'/'acn'/'medicare'/'crn'/'ihi'/'bsb') — each with the page and exact coordinates (in PDF points) the redaction engine needs. Use this FIRST so you select regions by entity ('redact every TFN') and pass the returned coordinates straight to redact_pdf, instead of guessing geometry from a rendered page. Numeric kinds are check-digit validated where a published algorithm exists (CRN has none — its matches are format-only). Candidates are best-effort pattern matches for review — not a completeness guarantee and not a compliance assessment; the file is never uploaded — detection runs locally. Each candidate carries a MASKED preview (e.g. '•••-••-6789'), never the raw value: the secret stays on the machine. You don't need the plaintext to redact — drive it by page + coordinates. (A human reviewer has the file open locally for full context.) Free tier (no native engine): results are EVALUATION-marked and limited to a monthly number of free checks, counted locally — past the cap this tool returns a structured 'free-cap' refusal. A configured licensed engine is not capped.

Locate exact text strings in a PDF and return each occurrence's page and coordinates (in PDF points). Use this for what pattern-matching can't catch — names, addresses, account references — by doing the entity recognition YOURSELF and passing the literal strings here; the engine resolves where they sit so you never guess geometry from a rendered page. Feed the returned regions straight to redact_pdf. Case-insensitive; a string the PDF splits across text operators may not match as one run. Each hit returns a masked preview, not the raw text. Nothing is uploaded.

Find and redact PII in a PDF in ONE on-device step: scan, keep only the requested entity kinds (email/ssn/phone/card plus the Australian tfn/abn/acn/medicare/crn/ihi/bsb — omit kinds to redact every kind detected), remove them, verify, and return what was redacted plus the audit log. This is the 'just scrub the obvious PII' shortcut; when you need to review before removing, call find_sensitive_regions first. Same caveat as the detector: matches are best-effort pattern matching, not a completeness guarantee and not a compliance assessment. Nothing is uploaded.

Permanently redact regions of a PDF on-device using Omitly. Removes the underlying text and image data (not a black box over it), verifies nothing survives in each region, and returns a signed audit log. The file is never uploaded — redaction happens locally.

Re-scan an already-redacted PDF on-device and confirm nothing recoverable remains. With a configured native engine and this file's own <path>.audit.json sidecar (written by redact_pdf/redact_by_entity), this re-checks exactly the regions that were redacted — the strongest form of this check. Without a native engine (or without that sidecar — e.g. the file wasn't redacted by this tool), it falls back to a general on-device re-scan of the whole file and reports whether anything is still detectable — a good-faith re-check, not a claim of the same rigor as the sidecar-based path.

Verify a PDF's embedded Omitly audit report and trailing Ed25519 tamper-evidence seal — on-device, nothing uploaded. Distinct from verify_redaction: that tool re-checks whether redacted regions are still empty; this tool cryptographically checks whether the delivered bytes have changed since they were sealed. The seal proves INTEGRITY, NOT IDENTITY: the signing key is per-install and travels with the file, so a valid seal means 'unchanged since sealed by the holder of this key', never 'produced by Omitly'. Compare sealFingerprint out-of-band against the fingerprint the sender published if origin matters. Requires a configured native engine — there is no wasm seal-verification path, so this always needs OMITLY_ENGINE_DIR/OMITLY_REDACT_BIN. A seal_unsupported_version verdict means this verifier is too old to check the seal at all — that is neither a pass nor a fail; update the verifier rather than trusting or rejecting the file on that basis.

Generate a clean PDF from Markdown (or raw HTML) on-device, rendered through a real browser engine so it looks printed — not like a script's best guess. Give it Markdown inline via source (or a file via sourcePath) and an outputPath; it writes the PDF and returns the path. Use this instead of writing a one-off reportlab/LaTeX/pandoc script. Nothing is uploaded.

Audit an ALREADY-redacted PDF and report whether sensitive text still survives underneath the redaction — the 'did my black boxes actually remove the data?' check. Most tools redact by drawing a rectangle over text while leaving the characters in the file, where they stay selectable and extractable. This re-extracts the text on-device and flags any emails, SSNs, phone or card numbers that are still present, each with a MASKED preview — the raw value never leaves the machine. It checks the page text layer, text surviving UNDER redaction marks, incremental-update prior revisions (the classic 'redacted then saved, original still in the file' failure), document metadata, AcroForm field values and embedded attachments, and returns a coverage report so a clean result is scoped to what was inspected. A non-empty result means the redaction leaked. Nothing is uploaded. (Pattern-based: names/addresses, image-only text, and the surfaces listed as not-inspected aren't covered; absence of hits isn't proof of completeness.) Free tier (no native engine): reports are EVALUATION-marked — for evaluation, not production reliance — and limited to a monthly number of free checks, counted locally; past the cap this tool returns a structured 'free-cap' refusal. A configured licensed engine is not capped.