How to verify Sensitive mode

You can check this yourself: open DevTools → Network, process a file, and confirm no request carries your document. Here's exactly how, in about two minutes.

1. Open DevTools before you pick a file

On desktop Chrome, Edge, or Firefox, press F12 (or Cmd+Option+I on macOS) to open DevTools, then click the Network tab. Do this before selecting Sensitive mode, so you capture every request from the start.

2. Clear the log and select Sensitive mode

Click the "clear" icon (a circle with a line through it, or the 🚫 icon) in the Network panel to start from an empty list. Then, on any tool page, choose Sensitive document — process only on this device. You'll be taken to device.dailytoolnest.com — a separate origin from the main site.

3. Process a real file

Select or drop a file, adjust any options, and click Process. Let it run to completion and download the result. This is the point where, if we were sending your file anywhere, you'd see it in the Network panel.

4. Inspect what actually happened

Look at the Network panel's request list. You should see:

• A small number of GET requests, all for files that loaded when the page first opened (JavaScript, WebAssembly, fonts, CSS) — not new requests triggered by your file.
• Zero requests with a request method other than GET or HEAD.
• Zero requests to any host other than device.dailytoolnest.com.
• Zero WebSocket connections (check the Network panel's "WS" filter).

Click on any request to inspect its size and payload — none of them will contain anything resembling your file's content, and none of them fire while or after your file is being processed.

5. Check the Content-Security-Policy, if you want to go further

In the Network panel, click the top document request and look at the Response Headers for Content-Security-Policy. On device.dailytoolnest.com it includes connect-src 'none' — this doesn't just describe our intent, it's a browser-enforced rule that blocks fetch(), XMLHttpRequest, WebSocket, and sendBeacon calls outright, for any script running on that page, including ours. If our own code ever tried to send your file somewhere, your browser would refuse the request and you'd see a CSP violation in the Console tab instead of a network request.

What this does and doesn't prove

This confirms that, for the version of the site you loaded, no request carrying your document left your browser during that session. It's a direct, repeatable check you can run yourself every time — we'd rather you verify it than take our word for it. See Security architecture for how the two-origin split and CSP enforcement work underneath this.