Measured, not promised
Your file never leaves this tab
Every other free tool asks you to upload your document to a server you cannot see. OpenTools does the work inside the page that is already open. That is easy to say, so we wrote a test that actively tries to smuggle data out of this site and records what happens. Below is the protocol, the result, and how to catch us if we are wrong.
Check it yourself in 30 seconds
You do not need to trust this page. Your browser already ships the instrument.
- 1Open any tool on this site, then open your browser’s developer tools and select the Network tab.
- 2Tick Preserve log, then filter to Fetch/XHR.
- 3Run your file through the tool and watch the list. Every request you see should be a
GETfor this site’s own JavaScript and CSS, fetched before you picked a file. Your document should produce no row at all.
If you ever see a request carrying your file — any POST, any off-site host, any row with a request body — that is a bug, and we want to know. The whole product rests on that list staying empty.
What our own test does
It runs in Chromium and WebKit against the production build, as part of the ordinary test suite. Three checks, ordered by how much each one proves.
1. The served policy forbids connections
Asserted against the response header of a real tool page, not against source code:
- connect-src 'none'
- fetch, XHR, WebSocket, EventSource and sendBeacon, together
- default-src 'self'
- everything not named below stays same-origin
- form-action 'none'
- no form can post anywhere
- object-src 'none'
- no plugin surface
- base-uri 'self'
- <base> cannot be repointed to redirect relative URLs
2. Deliberate exfiltration is refused
Watching an idle page proves only that nothing happened to fire. So the test attacks its own site: five vectors are actively attempted from the page’s own context.
- fetch → third partyRefused. Violates connect-src 'none'
- fetch → same originRefused, same directive
- XMLHttpRequest → third partyRefused. Chromium reports failure reason csp
- WebSocketRefused. WebKit throws SecurityError at construction
- navigator.sendBeaconRefused by CSP
3. A real file, through a real tool
An 86,563-byte PNG was generated in the page, handed to /image/optimize exactly as a file picker would, and optimised down to 3.1 KB. What the network recorded for the whole document:
- 17 same-origin requests, all
GETfor static JavaScript and CSS. Twoblob:URLs, which are in-memory and never leave the device. - 0 requests with an initiator type capable of carrying a body.
- 0 bytes to any off-origin host.
- The file’s name appears in no request URL.
Result: 6 of 6 checks passed, in both Chromium and WebKit, run 20 September 2026 against the production build of this release. The detector is not vacuous: pointed at a page that genuinely loads a cross-origin resource, it fails and catches the response.
What this does not prove
A page that overstated this would be worth less than one that says nothing, so here is the boundary.
- The run covers the tools and the two browser engines named above — not every tool, every browser, or every device.
- One route is deliberately not
connect-src 'none'. The background remover is servedconnect-src 'self'so it can fetch its model and WebAssembly runtime from this same site — never from a third party, and never carrying your image. - It says nothing about the visit log described below, or about Cloudflare’s own platform logs, which record that a page was requested in the ordinary way any web server does.
- It is not a security guarantee. Egress evidence reports where bytes went; it can never establish that no flaw remains. That is why phrases like “zero data leaks” were removed from this product rather than re-argued.
- The figures above belong to the release dated above. A later release is covered only once the protocol is re-run against it, which is a condition of shipping one.
For IT and security reviewers
If you are deciding whether staff may use this site for documents that must not be uploaded, these are the facts that usually decide it.
- No account, no sign-in and no cookie is required to use any tool.
- There is one server-side log, and this is all of it. Each page request writes a single event recording: country (from Cloudflare’s country header, no region or city), device type, the referring site’s category, the page path, primary browser language and a timestamp. It records no IP address, no raw referrer, no user agent, no cookie, and no file, filename, pasted text or result. Static assets are not logged at all.
- No analytics script and no third-party origin. Cloudflare’s own Web Analytics beacon was switched off at source on 19 September 2026, so the absence of trackers no longer depends on the content-security policy catching one.
- The source is public and MIT-licensed, and the egress protocol ships with it. Re-run it yourself against any build:
npx playwright test e2e/egress-proof.spec.ts - Allow-listing
getopentools.comgrants no outbound path for file contents: the served policy blocks fetch, XHR, WebSocket, EventSource, sendBeacon and form posts alike.
Protocol run 20 September 2026 against the production build of this release. Every figure on this page comes from that run.