DEV Community: Venkat Dixit Kallepalli

"Your file never leaves your device": how to test that claim (and the Chromium catch)

Venkat Dixit Kallepalli — Sat, 10 Oct 2026 01:27:27 +0000

Lots of web tools now say "runs in your browser, nothing is uploaded". I make one of them
(Drible, 53 file tools, 48 of which run client-side), and at some point I
realised the claim was just a sentence on a page. Nothing would fail if a refactor, a new
dependency or an analytics script started sending files somewhere.

So I turned the promise into a test. This post is how it works, including a gotcha in Chromium
that makes the obvious version of the test pass when it shouldn't.

The idea

Run a real job in a real browser (sign a PDF, merge two PDFs, compress a photo, convert a HEIC)
and record every network request the page makes while doing it. If any request could have
carried the file, fail.

"Could have carried the file" needs a definition. I used two checks:

Does the body contain a file signature? PDFs start with %PDF, JPEGs with FF D8 FF, PNGs with 89 50 4E 47, and HEIC files contain ftypheic. If any of those bytes appear in a request body, the file (or part of it) went out.
Is it anything other than a plain GET? Even without a visible body, a POST or PUT is a way to send data.

The only request allowed through is the analytics beacon, and only if it is small.

The test (Playwright)

const FILE_MAGIC: [string, Buffer][] = [
  ['PDF', Buffer.from('%PDF')],
  ['JPEG', Buffer.from([0xff, 0xd8, 0xff])],
  ['PNG', Buffer.from([0x89, 0x50, 0x4e, 0x47])],
  ['HEIC', Buffer.from('ftypheic')],
];

const BEACON = /\/cdn-cgi\/rum\b/; // Cloudflare Web Analytics, cookieless
const BEACON_MAX_BYTES = 4096;

function watchRequestBodies(page: Page) {
  const sent: { method: string; url: string; bytes: number; carries: string[] }[] = [];
  page.on('request', (r) => {
    const body = r.postDataBuffer();
    const method = r.method();
    if (['GET', 'HEAD'].includes(method) && (!body || body.length === 0)) return;
    sent.push({
      method,
      url: r.url().split('?')[0],
      bytes: body ? body.length : 0,
      carries: body ? FILE_MAGIC.filter(([, m]) => body.includes(m)).map(([n]) => n) : [],
    });
  });
  return sent;
}

const possibleUploads = (sent) =>
  sent.filter((s) => s.carries.length > 0 || !(BEACON.test(s.url) && s.bytes <= BEACON_MAX_BYTES));

And a job:

test('Merge PDF', async ({ page }) => {
  const sent = watchRequestBodies(page);
  await page.goto('/pdf/merge');
  // upload two fixtures, click Merge, wait for the download...
  expect(possibleUploads(sent), 'only the analytics beacon may send data').toEqual([]);
});

I picked one tool per technique, because that is where an accidental upload would come from:
the PDF editor (Sign PDF), a pdf-lib tool (Merge), a Canvas tool (Compress Image) and a
WebAssembly tool (HEIC to JPG, which runs libheif compiled to WASM).

The catch: the test passed when it should have failed

A test that never fails proves nothing, so I added a control: run one of our five tools
that does upload (PDF compression with Ghostscript on the server) and assert that the detector
catches it.

In Firefox the control passed. In Chromium it failed: the detector saw no upload at all.

The reason: when a page sends a file as a Blob or File (which is how FormData uploads and
most XHR/fetch uploads go out), Chromium does not expose that body through the DevTools protocol
that Playwright uses, so postDataBuffer() comes back empty. If the test had only looked for
file signatures in bodies, every upload in Chromium would have been invisible, and the "privacy
test" would have been green forever.

That is why the detector also treats any non-GET request as suspicious, whatever its visible
body. The upload shows up as a POST to /api/... even when Chromium hides its contents, and the
control now passes in every browser:

test('control: a server tool is detected as uploading', async ({ page }) => {
  const sent = watchRequestBodies(page);
  await page.goto('/pdf/compress');
  // upload sample.pdf and click Compress...
  await expect
    .poll(() => possibleUploads(sent).some((s) => s.url.includes('/api/')), { timeout: 90_000 })
    .toBe(true);
});

If you write a test like this for your own tool, add the control first. Without it you are
testing your detector's blind spots, not your app.

Where it runs

The suite runs every night against production (not a local build) in Chromium, Firefox and
WebKit, so it also catches things that only exist in production: a CDN script, an injected
analytics tag, a header change. Four jobs plus the control take about 15 seconds per browser.

What it does not prove

Honest limits, because "provably private" gets thrown around a lot:

It covers the jobs it runs. A different tool, or a code path the test doesn't click, is not covered (that's why it samples one tool per technique).
It watches the page's network requests. It is not a substitute for a tight Content-Security-Policy, which is the other half: ours limits where the page may connect to a short allowlist (our own origin, the analytics endpoint, and the CDNs that serve fonts and the background-removal model).
It says nothing about the 5 tools that are server-side by design. Those are labelled on the page, and the server deletes the file right after responding.

Check any site yourself in a minute

You don't need Playwright to check a site that makes this claim (including mine):

Open the tool and DevTools (F12) > Network.
Run a job with a harmless file.
Look for any POST or PUT, especially one roughly the size of your file. In Chromium, don't expect to see the file in the payload tab; the request itself is the tell.
Optional: load the page, turn off Wi-Fi, and run the job again.

If you build one of these tools, I'd love to see more of them ship a test like this. It's about
60 lines and it turns a marketing sentence into something that fails CI.

More on how Drible splits browser and server processing: How it works.

Real PDF redaction in the browser (a black box is not enough)

Venkat Dixit Kallepalli — Wed, 07 Oct 2026 00:53:16 +0000

Most "redact PDF" tools draw a black rectangle on top of the text and save. The text is still
there. Select it, copy it, or open the file in any PDF library, and it comes straight back.
Courts, journalists and HR teams have all leaked documents this way.

I build Drible, a free set of file tools where most of the work happens in
the browser. When I added redaction to the PDF editor, I wanted it
to be real redaction, done without uploading the file. Here is how it works and what I learned.

Why the black box fails

A PDF page is a content stream: a list of drawing operators like "move here, show these glyphs,
fill this path". Drawing a black rectangle just appends one more operator. The glyphs underneath
are untouched, so:

text extraction (and Ctrl+A, Ctrl+C) still returns them
search still finds them
the original objects can still be read from the file even if nothing on the page draws them

So removing the visible text is not enough. You have to remove every object that could still
hold it.

The approach: rebuild the page from pixels

Rewriting a content stream to delete exactly the glyphs under a box is hard in general (text can
be split across operators, use custom encodings, sit inside form XObjects, and so on). For a
browser tool I chose a simpler guarantee: a page with redactions is replaced by an image of
itself, with the boxes burned in.

Render the original page with PDF.js to a canvas at about 200 DPI (longest side capped at 5000 px so phones don't run out of memory).
Fill each redaction box on the canvas in solid black.
Encode the canvas as a JPEG and embed it on a fresh page of the same size with pdf-lib.
Remove the old page.

The new page contains only an image, so there is nothing to select, search or extract under the
boxes. The trade-off is that the rest of that page also becomes an image. Pages without
redactions are left untouched, so their text stays selectable.

The part people miss: the old page is still in the file

Removing a page in pdf-lib takes it out of the page tree, but its objects (content streams,
fonts, images, annotations) can still be sitting in the file. A PDF reader won't show them,
but anyone who opens the file in a text editor or a PDF library can. Two more steps close that:

Scrub the old page. Before it is dropped, its content, resources and annotations are deleted
from the page dictionary. Form fields whose widgets lived on that page are removed too, because a
field's value can hold the very text you redacted.

Garbage-collect unreachable objects. Walk the object graph from the trailer (the document
catalog and the info dictionary), mark everything reachable, and delete everything else:

/** Delete every indirect object not reachable from the trailer. */
function collectGarbage(pdf: PDFDocument): void {
  const ctx = pdf.context;
  const seen = new Set<string>();
  const stack = [ctx.trailerInfo.Root, ctx.trailerInfo.Info].filter(Boolean);
  while (stack.length) {
    const o = stack.pop();
    if (o instanceof PDFRef) {
      const key = o.toString();
      if (seen.has(key)) continue;
      seen.add(key);
      const target = ctx.lookup(o);
      if (target) stack.push(target);
    } else if (o instanceof PDFDict) {
      for (const [, v] of o.entries()) stack.push(v);
    } else if (o instanceof PDFArray) {
      for (const v of o.asArray()) stack.push(v);
    } else if (o instanceof PDFStream) {
      stack.push(o.dict);
    }
  }
  for (const [ref] of ctx.enumerateIndirectObjects()) {
    if (!seen.has(ref.toString())) ctx.delete(ref);
  }
}

pdf-lib then writes a clean file without the orphans. A quick way to test any redaction tool:
redact a unique word, save, then run pdftotext out.pdf - | grep yourword or open the file in a
text editor and search for it. If it shows up, the redaction did not work.

Everything else stays real PDF

Redaction is the only feature that turns a page into an image. Everything else the editor adds is
written into the original file as real PDF content:

text is real text in a standard PDF font, so it stays selectable and searchable
shapes and freehand ink are vector paths
images and signatures are embedded once and reused

Because the original file is modified rather than re-created, its existing text, links and form
fields survive.

Why do it in the browser at all

A file you redact is, by definition, a file with something sensitive in it. Uploading it to a
server to remove the sensitive part is backwards. Doing it client-side means the PDF is opened,
edited and saved on the user's device; the server only ever sends the JavaScript.

48 of Drible's 53 tools work like this. The 5 that need desktop software (PDF compression with
Ghostscript and the Office conversions) do upload, say so on the page, and delete the file as
soon as the result is sent back. I wrote up which popular PDF sites upload your files and how to
check if you want the comparison.

If you try the editor and manage to recover redacted text from a
file it saved, I'd really like to hear about it.