Why We Never Upload Your Files (How to Verify)

If you type "redact PDF online" into a search engine you'll find dozens of tools that look like RedactID. They have a drop zone, a black-rectangle tool, a download button. They work.

They also, almost without exception, upload your document to a server.

That's a big deal if you're redacting an ID, a tax form, a bank statement, a medical record, or anything else whose whole point is that the sensitive version should stop existing as soon as possible. The moment you upload a file to someone else's server, you have to start trusting:

• that the server isn't logging the file for debugging
• that the "deleted after processing" promise is actually implemented
• that the company hasn't been breached (without telling you)
• that their subprocessors haven't been breached
• that a law-enforcement subpoena or rogue employee can't recover it
• that the encryption-at-rest claim is real and the keys aren't on the same server
• that a future version of the tool doesn't quietly start retaining files

Every one of those is a reasonable thing to trust for most SaaS products. For a redaction tool specifically, the whole value proposition crumbles the moment any of them fail.

We picked a different architecture. RedactID never sends your document to a server. The drop zone you see, the OCR, the pixel-destructive redaction, the PDF rasterization, the final export — all of it runs in your browser's memory, on your device, using your CPU.

This post is the technical honest version of that claim. What we actually do, what it costs us to do it this way, and — most importantly — how you can verify the claim yourself without having to take our word for any of it.

What "processed in your browser" actually means

Every modern browser is a surprisingly capable runtime. It has a canvas API that can paint pixels. It has a FileReader that can read local files without a network round-trip. It has enough compute to run a full OCR engine (Tesseract.js, compiled from the same source Google open-sourced). It has a PDF renderer (pdf.js, maintained by Mozilla) that can turn a PDF into rendered pages without phoning home.

Those four pieces are all you need to do document redaction well:

Read the file locally. FileReader.readAsArrayBuffer takes a local file off your disk, or URL.createObjectURL creates a memory-only reference to it. Neither of them involves the network.

Render it visually. For an image, we draw it to an HTML canvas. For a PDF, pdf.js renders each page to a canvas at high resolution.

Detect and mark sensitive regions. Tesseract.js runs OCR on the canvas to find text. You draw boxes over the regions you want hidden. Nothing in that loop crosses the network.

Destroy the pixels. When you hit "Redact & Download", we paint opaque black pixels (or blur, or pixelate) directly onto the canvas at the coordinates of your boxes. The original pixels are overwritten in memory, then the canvas exports a new PNG or PDF.

The critical property is that step 4 is destructive. There is no "original" hidden underneath — the bytes that used to contain your ID number are gone, replaced with #000000 pixels. When we wrap the output into a new PDF, we wrap only the redacted images — we never copy a text layer, an annotation, or any metadata from the source PDF. The output PDF is structurally a collection of images, nothing more.

That's the architectural reason why /verify can confidently say "no recoverable text" when we analyze a RedactID export: there genuinely isn't any. It's not encrypted, not hidden — it's not there.

The things we gave up to do it this way

It'd be dishonest to pretend this architecture has no trade-offs. It has several, and we think they're worth naming.

We don't have cloud AI. Most modern redaction tools use server-side LLMs or vision models to auto-detect sensitive fields. We don't, because running those models requires sending your document to a server with a GPU, which would break the no-upload promise. Our OCR runs in the browser and is less sophisticated than cloud AI. We compensate by making manual box-drawing fast and by suggesting common redaction regions from OCR output, but a user who wants "AI, just do it for me" has to pick a different tool — one with a different privacy model. PDFs are desktop-only. Rendering a multi-page PDF to canvases in a mobile browser is memory-intensive, and mobile Safari in particular will kill the tab under load. We'd rather be honest about the limitation than ship a version that crashes or silently produces a partial redaction. Images work on any device; PDFs require a laptop for now. We can't save your work across devices. Your document and your in-progress redactions live in one browser tab's memory. If you close the tab, they're gone. A server-backed tool could give you a "Continue later" button; we can't, without contradicting the whole model. The credits associated with your account sync across devices; the documents themselves never do. We ship slower than we could. Any feature that would naturally run on a server — team collaboration, shareable review links, enterprise audit logs — has to be re-thought from the ground up to work without the server seeing the document. That's a meaningful tax on our roadmap. We can't run server-side security scanners on your file. Some tools advertise "virus-scanned uploads" or "malware-detected PDFs". We can't offer that because we never have your file on our servers to scan. We think it's a fair trade — the biggest malware surface for a redaction flow is the server itself holding onto your doc — but it's a real thing we don't do.

These aren't pain we're hiding behind marketing copy. They're the straightforward cost of keeping your document on your device. When the math stops working — when too many users really need AI features more than they need privacy — we'll either have to change the model and tell you, or lose those users. For now, we think the trade is the right one.

How to verify the no-upload claim yourself

The whole point of this architecture is that you don't have to trust us. The browser ships with tools to confirm or deny every word of this post, and they take about 60 seconds to use.

Check the Network tab

Open DevTools (F12, or Cmd+Option+I on Mac) and click the Network tab. Make sure "Preserve log" is checked. Now do a full redaction: upload a document, wait for OCR, draw a box, hit download.

Scroll through the requests. Sort by size. You will find:

• /api/usage — a tiny JSON ping that asks "can this user redact right now?" and returns a yes/no. No file content.
• Static assets — fonts, CSS, JS bundles, images. These are the same on every page load; none of them contain your document.
• Analytics pings — Vercel Web Analytics sends a cookieless beacon on page load with a URL and a referrer. No file.

Your file is not in that list. There's no request whose body contains a multi-megabyte binary payload with your name on it, because we never send one. If one day there is, we've broken the promise and you'll see it immediately in your browser.

Check /verify on your output

Take the PDF or image that RedactID gave you and drop it into /verify. That tool is open about what it looks for: extractable text, annotation layers, identifying PDF metadata, JPEG EXIF. A RedactID export should come out with "Looks clean" — no text (because the output is image-based), no annotations (because we draw directly on pixels, not on annotation layers), and no metadata that didn't exist in your original upload.

If a RedactID export ever comes back with a critical finding in /verify, we have a bug — tell us at support@redactid.io and we'll fix it the same day. That's a hard commitment. Our own verifier auditing our own output is, by design, the tightest possible loop.

Read the audit document

We maintain a running claims audit at AUDIT_CLAIMS.md in the repo. It lists every public-facing claim we make on the site, maps each one to the code that's supposed to enforce it, and marks items that are honest, items that slightly oversell, and items fixed during the audit. The no-upload claim is the first row.

Trust the CI check instead of us

The manual Network-tab check is useful, but we don't want the no-upload promise to depend on anyone — us or you — remembering to look. So we also wrote an automated tripwire: tests/no-upload-tripwire.spec.ts runs in CI on every pull request. It opens the app in a real browser, does a full image redaction and a full PDF redaction, and fails the build if any outbound request (a) goes to a host we don't own, (b) carries a body larger than 50KB, (c) uses a suspicious path like /upload or /files, (d) has a binary content-type, or (e) contains a distinctive slice of the uploaded file's bytes. Writing this test is also how we found and fixed two third-party CDN dependencies (pdf.js's worker and Tesseract.js's training data) that had been quietly sending a "this user is redacting right now" ping to Cloudflare and jsdelivr on every use — neither saw file content, but they saw usage metadata, which is exactly the sort of thing this architecture is supposed to prevent. They're now vendored and served from our own origin.

Read the code

RedactID is not open source yet, but the browser receives the entire application as JavaScript, which means you can read every line that processes your document if you want to. In DevTools → Sources, look for lib/redaction.js (the pixel painter), lib/pdf-export.js (the PDF writer), and lib/ocr-tesseract.js (the OCR invoker). None of them contain a network call that sends file bytes. If they ever do, you'll see it.

Bottom line

A privacy promise should be checkable. Most of them aren't — they're marketing copy attached to a server-side architecture, asking you to trust a lot of invisible infrastructure. Client-side processing doesn't require you to trust us, because there's no server-side infrastructure to trust in the first place. The file is on your device. It stays there. We can't see it because we don't have it.

We built RedactID this way because "nothing ever uploaded" is the only promise that survives contact with reality — survives a breach, a subpoena, a subprocessor change, an angry employee, a misconfigured log aggregator, a bug we didn't notice for six months. If the document isn't on our server, none of those things can expose it.

If you want to start the redaction and verifier loop now:

• Redact a document — upload, redact, download, all in your browser.
• Verify a redaction — drop a redacted file and we'll tell you if it actually hides what you think it hides.

Both pages run on the architecture this post is about. You don't have to take any of this on faith.