ConvertUnlimited

Trust Center

How to verify local processing

Trust claims should be testable. You can inspect the Network panel, run the privacy build audit, and run the no-network processing test against representative workflows.

Short answer

Open DevTools before selecting a file, clear the Network log, run the tool, and confirm processing does not create third-party or upload requests. For repository verification, run npm run verify:privacy.

Build boundary

Verification path

Use the verification page, browser DevTools, and repository privacy tests to inspect the behavior instead of relying on marketing language.

Browser DevTools check

What appears on the public build

What appears on the privacy build

The same tool pages load the same libraries, but from same-origin paths such as /vendor/jszip-3.10.1.min.js and /vendor/pdf-lib-1.17.1.min.js instead of a CDN host. No Google Tag Manager, AdSense, or Google Fonts request should appear.

Because the privacy build's CSP sets connect-src 'none', fetch, XHR, WebSocket, EventSource, and sendBeacon calls should fail in a supporting browser after the page has loaded, independent of what the Network panel shows.

Exact CSP header

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

How to inspect the CSP header yourself

In DevTools, open the Network panel, click the top-level document request (the HTML page itself), open its Headers tab, and read the content-security-policy entry under Response Headers. It should match the string above exactly.

From a terminal, curl -sI https://privacy.convertunlimited.com/ prints the same response headers, including content-security-policy, referrer-policy, and permissions-policy, without loading a browser.

Repository checks

The repository includes static and runtime checks for the privacy artifact. The static audit scans for known third-party runtime references. The runtime test blocks common network APIs while exercising representative processing flows.

npm run build:privacy
npm run audit:privacy
npm run test:privacy-network
npm run verify:privacy

What the runtime test actually does

Related proof page

The existing proof page summarizes the privacy artifact, verification command, network isolation model, and threat-model limitations.

Trust topics

FAQ

What should I look for in the Network panel?

Does a clean Network panel prove all security properties?

No. It verifies a narrow behavior: whether the tested processing flow caused network requests.

Can browser extensions affect the result?

Yes. Extensions can inject scripts or inspect page data depending on their permissions.

What does npm run audit:privacy check that a manual DevTools pass cannot?

It scans every generated file for a fixed list of disallowed hostnames and phrases, including hosts that might only load conditionally and never appear during one manual test run.

Does the runtime test cover every tool?

No. It exercises three representative flows: the homepage image converter, the metadata remover, and the background remover. Other tools follow the same architecture described in Local processing but are not individually scripted in this test.

Can I change the ports the test uses?

Yes. Set PORT for the local HTTP server (default 4187) and CHROME for the Chrome binary path; the CDP debugging port is fixed at 9233 in the script.

Review note

Trust documentation reviewed: May 2026. These pages describe the current public and privacy-build architecture and should be updated when deployment, telemetry, or runtime dependencies change.