RedactFile
LIVE
← Back to RedactFile
Technical ArchitectureGDPR · CCPA · Zero Data Retention

Privacy & Security Policy

Effective date: May 2026 · Applies to all users globally (US, EU, and beyond)

This document describes the technical architecture of RedactFile — not legal boilerplate. Privacy compliance here is a consequence of how the system is built, not a policy statement that could be reversed.

Zero server interaction. By construction.

All PDF operations execute in a browser Web Worker via WebAssembly. The architecture makes it technically impossible for file bytes to reach a server — there is no server endpoint that accepts them. This is verifiable: open DevTools → Network while processing a file and observe zero outbound requests carrying PDF data.

Core Architecture

How Client-Side Processing Works

When you open a PDF in RedactFile, the browser reads it using the File API into an ArrayBuffer — a raw binary representation that exists only in RAM on your device. This buffer is transferred (not copied) to a Web Worker thread via postMessage(buffer, [buffer]), which hands over ownership and zeroes the reference on the main thread.

// Main thread worker.postMessage({ op: 'redact', buf }, [buf]); // buf is now detached — zero bytes remain on main thread // Worker thread (isolated — no DOM, no network) self.onmessage = async ({ data }) => { const result = await processWithPdfLib(data.buf); self.postMessage({ out: result }, [result]); };

The worker operates in a sandboxed scope with no access to the DOM, no access to fetch or XMLHttpRequest, and no localStorage. The processed output is returned to the main thread and immediately offered as a browser download. No intermediate copy is retained.

  • File read: FileReader → ArrayBuffer — local RAM only
  • Processing: pdf-lib running inside Web Worker — sandboxed
  • Output: Blob URL → a.download — direct to device
  • Memory: buffer is detached and garbage-collected after each operation

Network Verification

Confirming Zero Upload — Yourself

You do not need to trust this document. You can verify the architecture in under 60 seconds using tools built into any modern browser:

  1. Open DevTools (F12) → Network tab
  2. Filter by Fetch/XHR. Clear the log.
  3. Drop a PDF and run any tool (Metadata Eraser, Redactor, etc.)
  4. Observe: zero new network requests appear. The only requests visible will be for static assets loaded before you dropped the file.

To go further, enable Preserve log and inspect the Headers pane on every request — none will contain PDF bytes or filenames.

Data Handling

What Is and Isn't Collected

RedactFile operates under a data minimisation by default principle. We collect only what is strictly necessary to operate the billing system. No personally identifiable information is derived from or associated with file processing activity.

Collected (billing only):

  • Email address — passed from Stripe checkout, stored in a signed JWT in your browser
  • Subscription tier (free or pro) and expiry timestamp
  • Stripe customer ID — held by Stripe, referenced in our Cloudflare Function

Never collected:

  • PDF file contents or binary data — no server endpoint exists to receive them
  • File names or paths
  • Metadata stripped from your documents (author names, GPS, custom fields)
  • IP address linked to any file operation
  • Browser fingerprint, canvas fingerprint, font enumeration
  • Advertising identifiers (no ad network integrations exist)
  • Cookies of any kind — the app uses zero cookies

Regulatory Compliance

GDPR & CCPA: Architecture as Legal Shield

RedactFile is not a legal entity making compliance claims. It is a technical system whose architecture makes certain privacy violations structurally impossible, which in turn satisfies the technical requirements of both frameworks:

🇪🇺 GDPR (EU)

  • ✓Art. 5(1)(c) — Data minimisation: only billing email stored
  • ✓Art. 5(1)(e) — Storage limitation: JWT expires in 30 days
  • ✓Art. 25 — Privacy by design: client-side processing enforced at architecture level
  • ✓Art. 17 — Right to erasure: delete the JWT, no residual data exists

🇺🇸 CCPA (California)

  • ✓No "sale" of personal information — no data transmitted to process
  • ✓Right to know: only billing email held, verifiable via JWT inspection
  • ✓Right to delete: clear localStorage to remove all stored data
  • ✓No cross-context behavioural advertising — no ad tech present

Note: This is a technical statement about system design, not a legal opinion. Users with specific compliance obligations should consult qualified legal counsel.

Authentication

Your Subscription Token (JWT)

After a successful Stripe checkout, our Cloudflare Function issues a signed HS256 JWT containing only three claims:

{ "email": "user@example.com", "tier": "pro", // "free" | "pro" "exp": 1780000000 // unix timestamp, 30-day window }

This token is stored in localStorage under the key redactfile_token and verified client-side only — it is never sent alongside PDF data (PDF data never leaves the browser). The token grants access to Pro features within the local JavaScript context.

  • Token contains no payment details, no card data, no address
  • Auto-expires after 30 days — subscription re-validates via Stripe webhook
  • Delete at any time: DevTools → Application → Local Storage → redactfile_token
  • Token is never transmitted alongside any PDF processing request — there is no such request

Third-Party Services

Exactly Three External Services

RedactFile uses exactly three third-party services. None of them receive PDF data.

StripePayment processing

Handles checkout and subscription lifecycle. RedactFile never sees card numbers. Stripe receives your email and payment method only. Subject to Stripe's Privacy Policy (stripe.com/privacy).

↗ Stripe Privacy Policy
Cloudflare PagesStatic asset hosting & edge delivery

Serves HTML, JS, CSS, and WASM files to your browser. Cloudflare's edge network routes these static assets efficiently. No PDF data transits Cloudflare infrastructure — the app runs entirely in your browser after the initial page load.

↗ Cloudflare Privacy Policy
Plausible AnalyticsPrivacy-preserving usage analytics (if configured)

Counts tool usage events (e.g. "redact used", "file size: 1–10 MB") with no cookies, no cross-site tracking, and no fingerprinting. Plausible does not receive file names or content. Events contain zero PII.

↗ Plausible Privacy Policy

Deleting Your Data

There is no account dashboard because there is almost nothing to delete. The only data RedactFile holds about you is a JWT in your own browser. To remove it completely:

// In any Chromium or Firefox browser: DevTools (F12) → Application → Local Storage → Select your redactfile origin → Delete "redactfile_token" // That's it. No email to send. No support ticket needed.

If you also want Stripe to delete your billing record, email privacy@redactfile.com and we will request deletion of your Stripe customer record within 30 days, consistent with Stripe's data retention requirements.

Questions about the technical architecture?

The implementation is open to inspection in your browser DevTools at any time. For compliance inquiries contact privacy@redactfile.com.

Back to RedactFile →