“Private” is an easy label to add to a web tool. The more useful question is narrower:
what happens to the bytes after a person selects a file?
PriviTools is built around a specific answer for its local tools: the selected file is read by
browser code, processed in browser memory or a Web Worker, and turned into a browser download.
The site still makes ordinary network requests to load the page and its dependencies. Local
processing does not mean that a web page is offline or that it never communicates with a server.
This distinction is important enough to verify in source code.
The PDF path
The PDF workbench reads each selected file with arrayBuffer(). PDF operations are sent to a
module Web Worker with postMessage(). The worker returns the result, and the page creates a
local blob: URL for the download.
That path has no upload step for the document. The relevant implementation is visible in the
PDF workbench
and its PDF worker.
The implementation also has explicit file-size checks. That is a better promise than claiming
that every browser can handle an unlimited document: practical limits depend on the device and
the browser's available memory.
The video path
Video and audio conversions use a Web Worker. The page reads the selected file into an
ArrayBuffer and transfers it to the worker. The worker loads the FFmpeg WebAssembly runtime
from a fixed CDN URL when needed, writes the input into FFmpeg's in-memory filesystem, runs the
conversion, reads the output, and transfers the result back to the page.
The important separation is this: downloading the FFmpeg runtime is not uploading the user's
video. The input bytes are passed to the worker and FFmpeg's in-memory filesystem. They are not
sent in the request that downloads the runtime. See the
video worker implementation.
The runtime also exposes the real trade-off. The browser must download FFmpeg before the first
conversion, and the result depends on local CPU, memory, and supported codecs. A privacy claim
does not remove those performance constraints.
The exception that must be stated
The PDF-to-Word implementation contains a development-only convenience path for a local helper
at localhost:4322. It is guarded by the build environment and is skipped in production. The
production path continues with the browser-side PDF parser and document generator.
That detail is why “there is no backend” is too broad as a technical statement. The accurate
statement is: production local-tool processing does not send the user's file to a PriviTools
processing server. A developer may still run an optional local helper while developing.
What does use the network?
The browser still downloads HTML, JavaScript, CSS, fonts, and some libraries. The feedback form
also sends a suggestion to Web3Forms when the visitor explicitly submits it. The form does not
attach the file being processed.
PriviTools keeps these actions separate from the file-processing path. The privacy policy
describes the distinction instead of pretending that a website has no network activity.
How the claim is tested
The repository includes an end-to-end privacy test that loads a canary PDF, watches outgoing
requests, searches URLs and request bodies for the canary markers, rejects large third-party
request bodies, and fails on an unapproved network origin.
The test covers the automatic redactor and the PDF upload widget directly. It also performs a
broader page-load sweep. This is reproducible evidence for the covered flows, not a certification
of every future browser, dependency, or tool.
The source is available in the
no-exfiltration Playwright test.
What this proves—and what it does not
The code supports a precise claim:
- local-tool file bytes are read and processed in the browser;
- PDF and media work is delegated to browser workers where appropriate;
- generated results are returned as browser-local downloads;
- the tested flows do not send the canary document to a third-party endpoint.
It does not prove that every website resource is local, that a compromised device is safe, or
that local processing automatically provides legal compliance. Those are different claims and
need different evidence.
That is the standard PriviTools should keep: make the privacy boundary specific, show the code,
test the network path, and document the exceptions.
Try the browser tools at PriviTools or inspect the reusable
client-side helpers in PDF Local Processor
and Privacy First Web Tools.
Top comments (0)