How to Check That an Online Tool Keeps Your File on Your Device

A claim on a page is not a check

Many sites say that your file never leaves your device. The sentence costs nothing to write, and you cannot see what a page does by looking at it. The three checks below take a few minutes, need no extra software and work on any site, including this one.

Each check answers the same question in a different way: did the file travel? The Network panel shows every request a page makes. A run with the connection off shows whether the work depends on a server at all. The caption on the page tells you in advance what the tool is going to do, so you can compare it with the other two.

We ran all three on October 19, 2026 on Compress PDF, which works in the browser, and on PDF to Word, which runs on our server. The numbers below come from those runs.

Check 1: watch the Network panel

Open the tool page, then open the browser's developer tools: F12 or Ctrl+Shift+I in Chrome, Edge and Firefox on Windows, Cmd+Option+I on a Mac. In Safari, turn on the Develop menu in the Advanced tab of its settings first. Pick the Network tab and keep it open while you add a file and run the tool.

Sort the list by size or filter it by method. A tool that sends your file produces a POST or PUT request about as large as the file, addressed to its own server or to a storage host. A tool that works on your device produces downloads instead: script files, fonts and the processing engine, all with the GET method, and all of them before the result appears.

On Compress PDF in desktop Chrome on October 19, 2026, a 429 KB file with 500 pages produced 55 requests. 53 were GET requests to pulsarkit.com for page code, fonts and the PDF engine. The other two were POST requests to the site's own analytics counter at /e, each a few hundred bytes with a 204 reply; a 429 KB file does not fit in a request that small. Nothing went to any other host.

What the counter records is described in the privacy policy. What it cannot carry is the file, and the panel is what shows that.

Check 2: run it again with the connection off

The Network panel needs a desktop browser. On a phone, use the connection itself. Open the page and run the tool once while you are online: the first run downloads the engine, which is why it takes longer than the second. Then switch on airplane mode, or turn off Wi-Fi on a laptop, and run the tool again with another file on the same page, without reloading it.

If the result appears, the work happened on your device: there was no server to talk to. If the page stops with an error or waits without end, the tool needs a server for that step, whatever the page says about it. Switch the connection back on before you reload: a fresh page load needs the engine again.

On October 19, 2026 we did exactly this with Compress PDF, with the connection switched off at the system level. A 6.6 KB PDF with images had gone through online first, down to 3.5 KB, 46% smaller. Offline, a second PDF of 429 KB went through as well and offered a download, while the browser reported itself offline the whole time.

Check 3: read the caption before you add the file

A tool that uses a server should say so where you add the file, not in a policy three clicks away. On PulsarKit, each server tool states it in the drop zone, together with the limits that come with a server. The caption on PDF to Word reads: up to 300 MB, up to 30 jobs an hour, uploaded to our server and deleted after processing; the result is wiped within about two hours (October 19, 2026).

We ran that tool with the panel open to see whether the caption holds. A 1.5 KB PDF produced five requests to jobs.pulsarkit.com: a POST that creates the job, a PUT that carries the file, a POST that starts processing, a GET that asks for the status and a GET that downloads the finished DOCX. That is what a server tool looks like in the panel, and it matches the caption.

Browser tools on PulsarKit carry a different caption. On Compress PDF it reads: each document is opened by your own browser, so nothing is uploaded and nothing waits in a queue. If a caption and the panel disagree on any site, trust the panel.

One tool sits between the two. Remove Background sends a reduced 1024 × 1024 copy of the photo to our server to find the subject and gets back only the mask; the cut-out itself is made in your browser from the original. The page says so in its caption and in its questions and answers (October 19, 2026): read it before you add a photo, then let the panel confirm it.

What a browser tool still downloads, and why that is fine

The GET requests are not a loophole. A browser tool has to bring the processing code to your device before it can run: page scripts, fonts to draw page previews and a WebAssembly engine, which can be several megabytes for video or text recognition. Those bytes come to you; nothing of yours goes out. It is also why the first run on a page is slower than the next one.

The same logic covers the result. On PulsarKit, a result stays in the tab, and the list under it passes the file to the next tool. When both tools run in the browser, that handoff happens on your device too.

Transfer is one question; metadata is another. A file that stays on your device can still carry an author name, a creation date or a location inside itself. Remove PDF Metadata and Remove Image Metadata strip those before you send the file on yourself.

Where to start

To see a browser tool in the panel, start with Compress PDF or Compress Image: both work on your device and show the size before and after in the result. To see a server tool for comparison, PDF to Word says in its caption what it does, and the panel will agree.

To try the offline check on a phone, use the tool you actually need, for example Merge PDF: run it once online, switch on airplane mode and run it again on the same page with other files. We measured Compress PDF this way on one day, in one browser, with two files; for any other tool, file or browser, the check gives the answer, not this article.