Proof of local processing.

Source code

The site and the privacy build are open source. Everything described on this page can be read and re-run from the public repository: github.com/dunkin-novice/convertunlimited.com. The specific files behind this page's claims are the generator scripts/build-privacy.js, the static audit scripts/audit-privacy-build.js, the runtime test tests/no-network-processing.js, and the policy documents THIRD_PARTIES.md, THREAT_MODEL.md, LOCAL_PROCESSING.md, and SECURITY.md.

Reviewed artifact

The privacy-reviewed artifact is dist/privacy-build/, generated by npm run build:privacy. It is designed to be served from a separate origin such as privacy.convertunlimited.com, deployed as the Cloudflare Worker convertunlimited-privacy declared in wrangler.jsonc, with dist/privacy-build bound as its static assets directory.

Mechanism: what actually happens in the tab

A typical image tool reads the selected file with the File API, decodes it onto a Canvas element, and re-encodes the result with canvas.toBlob; the output becomes an object URL that a download link points to. No file-ingest endpoint receives the bytes in that path.

As a concrete example, the background-remover tool's default mode calls canvas.getImageData to read pixel values, compares each pixel's color distance against a sampled edge color, and writes the result back with canvas.putImageData, driven by tolerance, feather, and subject-protection sliders in the page; the logic lives in background-remover/background-remover.js. Several PDF tools additionally require WebAssembly support in the browser, since the vendored PDF.js and pdf-lib libraries use it for parts of PDF parsing and rendering.

Uploads are not required when the browser can decode, transform, and encode the requested format locally; if a browser cannot decode a format, runs out of memory, or lacks an encoder for the output, a tool can fail or need a different workflow instead of silently succeeding.

Expected network behavior

After the static page assets are loaded from the same origin, file processing should not create network requests. The generated headers and an HTML meta tag both set a 13-directive Content Security Policy, including connect-src 'none', on the privacy build:

default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; media-src 'self' blob:; font-src 'self'; connect-src 'none'; worker-src 'self' blob:; object-src 'none'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; upgrade-insecure-requests

On the public site, the same tool pages instead load their runtime library directly from a CDN (cdnjs.cloudflare.com, unpkg.com, or cdn.jsdelivr.net depending on the library), plus a Google Tag Manager container and, on the homepage, an ad-loader script. Those are the requests a Network-panel comparison between the two builds should surface.

Local verification

git clone https://github.com/dunkin-novice/convertunlimited.com
cd convertunlimited.com
npm install
npm run verify:privacy

The verification command builds the privacy artifact, scans it for known third-party runtime references, opens it in a headless browser, blocks common network APIs, processes a sample image, and fails if network requests occur during processing. The test source is tests/no-network-processing.js. Concretely, it serves dist/privacy-build/ from a local HTTP server (port 4187 by default), launches headless Chrome over the DevTools Protocol, patches window.fetch, XMLHttpRequest.prototype.open, and navigator.sendBeacon to throw if called, then runs the homepage image converter, the metadata remover, and the background remover against a generated sample file. If you do not run code locally, the DevTools Network-panel method on the verification page checks the same property with no tooling, and also shows how to read the Content-Security-Policy response header directly.

Architecture summary

User-selected file
  -> Browser File/Blob APIs
  -> Local JavaScript tool logic
  -> Canvas/PDF/browser encoder
  -> Blob/Object URL
  -> Browser download

LOCAL_PROCESSING.md breaks this down per tool family: image conversion uses File, Image, URL.createObjectURL, and canvas.toBlob; image compression and resizing add FileReader and the vendored JSZip library for batch ZIP downloads; metadata removal uses FileReader, Image, and Canvas re-encoding; PDF merge, split, and compress use the vendored pdf-lib library with ArrayBuffer and Blob; PDF-to-images uses the vendored PDF.js library and a local worker file; developer text tools use browser string and Web Crypto APIs.

Important limits

The privacy build does not defend against a compromised browser, malicious extensions, host-level script injection, or operating-system telemetry. It is a static local-processing web app, not a sandbox for a compromised device.

Device and software limits also apply. A 12-megapixel photo occupies roughly 48 to 50 MB of memory once decoded onto a canvas regardless of its compressed size on disk, so large batches can use several gigabytes of memory. PDF tools carry no software-imposed file-count limit, but documents of 100 MB or more, or multi-hundred-page batches, can exceed a browser tab's available memory. The diff-checker tool enforces an actual hard guard: comparisons over 200,000 combined characters, or with a line-count product over 250,000, are blocked outright rather than attempted. The background remover's optional AI mode downloads an approximately 40 MB model on first use in the public build and is disabled with an explicit error in the privacy build. A fuller list, including what canvas-based metadata removal does not remove, is on the limitations page.