How to check if an online tool uploads your files

Short answer: open the browser’s developer tools with F12, select the Network tab, filter to Fetch/XHR, then run the tool on a file of about three megabytes. If a request leaves carrying roughly that many bytes, the file was uploaded. If the largest outbound request is a few kilobytes, it was not. Encryption does not hide this — HTTPS conceals a request’s contents from the network, never from the browser that sent it, and never its size.

Every online file tool claims to respect your privacy, including the twelve that were measured uploading a test document in the Filevane PDF upload audit. A claim is exactly what a tool that uploads your file would also make, so the six methods below are written to be used on any site — including this one. Filevane appears at the end as a worked example, not as the reason to read.

Six ways to check, from fastest to strongest

Each method states what it can establish and what it cannot. No single check settles the question on its own; a method presented without its limits produces confident wrong answers.

1. Watch the Network tab

30 seconds

Establishes: Whether the page sent your file anywhere while you were watching. An upload is a request whose payload is roughly the size of your file, and it cannot be hidden from the browser's own request log.

Does not establish: That the tool never uploads under other conditions — a different file type, a different option, or a later version of the page. It is a spot check, and a spot check is what most claims have never had.

Open the tool's page, then press F12 (or Cmd+Option+I on a Mac) to open developer tools.
Select the Network tab and filter to Fetch/XHR so page assets do not crowd out data requests.
Tick 'Preserve log' — some tools navigate or reload after processing, which would otherwise clear the evidence.
Add a file that is large enough to be unmistakable. Three megabytes is ideal: too big to hide inside an analytics ping.
Run the tool, then sort the request list by size.
Read the largest request. If a request carries roughly your file's size to a host you do not recognise, the file was uploaded. If the largest outbound request is a few kilobytes, it was not.

2. Read the Content-Security-Policy

30 seconds

Establishes: The complete set of destinations the page is PERMITTED to contact. The connect-src directive is enforced by the browser, not by the site, so it constrains what the site's code is able to do rather than describing what it intends to do.

Does not establish: That the operator will not widen the policy tomorrow. A header is a current fact, not a guarantee — which is why it is worth re-checking rather than remembering.

Run: curl -I https://example.com/ | grep -i content-security-policy
Find the connect-src directive. It lists every host the page may open a network connection to.
If connect-src is absent, the policy places no restriction on where data may be sent — the check has told you nothing reassuring.
If connect-src is present, every host on it is a destination the page can reach. Look up any you do not recognise.
Note that 'self' means the site's own origin, so a site with connect-src 'self' can still send your file to its own server.

3. Pull the plug

30 seconds

Establishes: That the processing happens on your device. A tool that finishes its work with the network disconnected cannot have used a server to do it. This is the single strongest test available to a non-technical user.

Does not establish: That nothing is sent when the network IS available. A tool can process locally and still transmit a copy.

Load the tool's page completely, with the network on.
Disconnect: turn off Wi-Fi, or tick 'Offline' in the Network tab's throttling menu.
Run the tool on a file.
If it completes and produces a correct result, the work was done in your browser. If it hangs or errors, a server was doing the work.

4. Inspect the request payload

2 minutes

Establishes: What a specific request actually contained. Sizes can mislead; the payload cannot.

Does not establish: Anything about requests you did not open. This is a follow-up to the Network tab method, not a replacement for it.

In the Network tab, click the largest outbound request.
Open the Payload (Chrome) or Request (Firefox) panel.
Look for a multipart form field containing binary data, or a base64 blob. Either is your file.
Check the Headers panel for the destination host and the Content-Length.
Encryption is not a defence against this check: HTTPS hides a request's contents from the network, never from the browser that made it, and never its size.

5. Read the source

10 minutes

Establishes: Which browser APIs the page can use to move data: fetch, XMLHttpRequest, WebSocket, navigator.sendBeacon, EventSource and form submission are the complete set.

Does not establish: Much, if the bundle is minified — which it usually is. Treat a clean reading as weak positive evidence and a suspicious one as a prompt for the payload check.

View source, or open the Sources panel and search the loaded scripts.
Search for: fetch( , XMLHttpRequest , sendBeacon , WebSocket , FormData .
For each hit, find the destination URL.
Remember that a mention inside a string is not a call — code that GENERATES a fetch() snippet for you to copy contains the word without ever making a request.

6. Measure it at the transport layer

developer

Establishes: Bytes actually sent per destination host, independent of what the page reports. This is the method behind the Filevane PDF Upload Audit, and it is reproducible against any site.

Does not establish: That a tool processes locally, on its own. Near-zero outbound traffic from a tool that never STARTED is indistinguishable from a tool that ran in the browser — which is why the harness also has to confirm the tool actually did its work before recording a result.

Drive a real browser (Playwright or Puppeteer) through a local proxy that counts bytes per host.
Load the target page, hand it a test file of known size, and start counting from that instant.
Wait for a completion signal from the page — a download, a result element, a state change.
Record bytes sent per host in the window between file selection and completion.
Classify: a transfer of at least half the test file to a named host is an upload. Near-zero bytes AND independent proof the tool ran is local processing. Anything else is not established, and must not be reported as a finding.

Readings that look like an upload and are not

Two tools in the Filevane audit initially read as processing locally purely because the harness had failed to start them. Silence is not evidence.

What you see	What it usually is
A large POST right after you pick a file	Often a crash reporter or session-replay script capturing the interaction, not the file. Open the payload and look at what is in it before concluding.
Traffic to a CDN while the tool runs	Usually an INBOUND download — a WebAssembly module, a font, an OCR language model. Check the direction: the number that matters is bytes sent, not bytes received.
No requests at all, and the tool 'worked'	Confirm the tool actually produced output. A tool that silently failed to start looks identical to one that processed your file locally. This is the most common way a privacy audit produces a false pass.
A request to the site's own domain	connect-src 'self' permits this, and it is where a same-origin upload would go. Same-origin is not the same as no-origin.
The page says 'files are processed locally'	That is a claim, not a measurement, and it is the claim every upload-based tool in the Filevane audit also made. It is the thing being tested, not evidence about it.

Worked example: checking Filevane

Applying method 1 to this site. The same five steps work on any competitor, and the comparison is the point of running it.

Verify it yourself in 30 seconds

Open any Filevane tool — Merge PDF is a good one, because the file is large and obvious.
Press F12 to open developer tools, and select the Network tab.
Filter to Fetch/XHR so you see data requests rather than page assets.
Add your PDF and run the tool.
Watch the list. Your file is never in it — because it never leaves the tab. Compare the same test on any upload-based converter and you will see the opposite: a multi-megabyte POST carrying your document.

Read the header yourself

You do not have to take this page’s word for what the policy says. Ask the server directly:

curl -I https://filevane.com/ | grep -i content-security-policy

Which returns the policy currently in force. At the time of writing that is:

default-src 'self';
script-src 'self' 'unsafe-inline' 'unsafe-eval' 'wasm-unsafe-eval' blob:
  https://www.googletagmanager.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: blob: https://www.google-analytics.com;
font-src 'self' data:;
connect-src 'self' blob: data:
  https://www.googletagmanager.com
  https://www.google-analytics.com
  https://formsubmit.co
  https://api.frankfurter.dev
  https://open.er-api.com
  https://en.wikipedia.org
  https://simple.wikipedia.org;
worker-src 'self' blob:;
object-src 'none';
base-uri 'self';
form-action 'self' https://formsubmit.co;
frame-ancestors 'self';
upgrade-insecure-requests

The directive that does the work

Everything rests on connect-src. It enumerates every destination this page is allowed to open a network connection to — every fetch(), XMLHttpRequest, WebSocket and beacon. A request to any host not on that list is refused by the browser before it is sent, and reported in the console as a policy violation.

This is the difference between a policy and a promise. We are not asking you to believe that our code chooses not to upload your file. We are pointing out that the browser will not let it, and inviting you to confirm that yourself.

Every third party we allow

Complete list, including the ones that are awkward to admit. If a host is not here, the browser blocks it.

Host	What it is for	What it can see
`'self' (filevane.com)`	The site's own code, styles and fonts.	Nothing you process. Static files are downloaded to you; nothing is sent back.
`blob: and data:`	In-memory objects — how a generated file reaches the download button.	Not a network destination at all. These never leave the browser process.
`googletagmanager.com, google-analytics.com`	Google Analytics 4 — page-view and traffic measurement.	Which pages are visited, plus the usual analytics data (approximate location, device, referrer). It has no access to files you open in a tool.
`formsubmit.co`	Delivers the contact form.	Only what you type into the contact form and submit deliberately.
`api.frankfurter.dev, open.er-api.com`	Exchange rates for the Currency Converter.	Which currency pair you asked about. No amount and no personal data is sent.
`en.wikipedia.org, simple.wikipedia.org`	Article search and text for the Quiz Generator's "From a topic" mode.	The topic you typed and the titles of the articles you chose. Only when you search by topic — files you add to the Quiz Generator are never sent.

What this does not prove

Being straight about the limits, because a claim that overreaches is worth less than one that does not:

We serve the header, so we could change it. The protection is that any change is public and checkable in one command — not that it is impossible.
Analytics is still a third party. Google Analytics sees your page views. It cannot see your files, but it is not nothing, and it is listed above rather than quietly omitted.
unsafe-eval genuinely weakens the policy. WebAssembly requires it. We would rather explain that than hide it.
Your browser and extensions are outside our control. A malicious extension with permission to read page content can read anything you open, on any site, including this one.

Sources

The behaviour described above is specified, not folklore. Each link is the primary source for the claim beside it.

MDN — Content-Security-Policy: connect-src — The normative list of APIs connect-src governs: fetch, XMLHttpRequest, WebSocket, EventSource, sendBeacon and the ping attribute.
W3C — Content Security Policy Level 3 — The specification itself, including how a violation is enforced and reported.
OWASP — Content Security Policy Cheat Sheet — Practical guidance on reading and writing a policy, and on what a weak one looks like.
Chrome DevTools — Network features reference — How to filter, preserve and inspect requests, including the Payload panel.
MDN — Firefox Network Monitor — The equivalent panel in Firefox, for readers not using a Chromium browser.

Methodology and dates

Method published: 2026-08-28
Header last verified: 2026-08-28 — by running the curl command above against the live site.
Measurement harness: scripts/upload-audit.mjs — the byte-counting method described in method 6, and the code behind the PDF upload audit.
Tool classification: 405 of Filevane’s 406 tools contain no network API anywhere in their source. The exception is the Currency Converter, which sends the two currency codes you selected in order to fetch a rate. That figure is produced by scripts/privacy-audit/scan-tool-network.mjs, which is re-run on every build rather than maintained by hand.

Frequently asked questions

How do I verify that my file is not uploaded?

Open your browser's developer tools (F12), select the Network tab, then run any tool on a file. Watch the request list: you will see the page's own scripts load, and no request carrying your file. Filter by 'Fetch/XHR' to make it unmistakable. This works in Chrome, Firefox, Edge and Safari, and it does not require trusting anything we say.

What is a Content-Security-Policy and why does it matter here?

A CSP is a header the server sends and the browser enforces. Its connect-src directive lists every destination the page is permitted to open a network connection to. Any attempt to reach a host not on that list is blocked by the browser itself and logged as a console error — so the policy is not a promise about our intentions, it is a restriction on what our code is able to do.

Could Filevane change the policy later?

Yes — the header is served by us, so a future version could widen it. That is why this page publishes the current policy rather than asking you to assume it: you can re-check it at any moment with a single command, and any change is immediately visible to anyone who looks. Verifiability is not the same as a guarantee, and we are not claiming otherwise.

Why does the policy allow 'unsafe-eval'?

WebAssembly needs it. The OCR engine (Tesseract), the PDF renderer (pdf.js) and the video tools (FFmpeg) are all compiled to WebAssembly, and instantiating a WASM module requires 'unsafe-eval' and 'wasm-unsafe-eval'. It is a genuine loosening of the policy, and it is the price of doing the processing on your device instead of ours.

Does Filevane use analytics?

Yes — Google Analytics 4, listed in the table above. It records page views, not file contents; there is no mechanism by which it could reach a file you open in a tool. We list it here rather than omitting it, because a privacy claim that hides its own analytics is not a privacy claim.

Do you store any files at all?

There is nowhere to store them. Filevane is a static site with no application server, no database and no file storage. A file you open exists in your browser's memory and is gone when you close the tab.

Found something that contradicts this page? That is genuinely worth knowing — please tell us, or report a security issue via security.txt. See also our privacy policy.