Verify No File Upload: Check If Your Privacy is Actual or Marketing

You should not have to trust a developer with your tax return, source code, medical records, or sensitive designs just because their landing page says "secure." If you want to verify that no file upload is occurring, you need objective evidence from your own browser, not marketing copy. Modern browsers provide the tools to get that evidence.

This verification process is not just for developers. If you can open a browser menu and click a few tabs, you can verify whether a tool sends your data to a server or processes it on-device. The upload-to-a-server model is structurally hostile to privacy. Once a file leaves your hardware, you are no longer in control; you are simply accepting a promise.

Verify no file upload using browser DevTools

The fastest way to verify no file upload is to monitor network activity while using the tool. Every major browser includes Developer Tools (DevTools), which expose every request the page makes, where those requests go, and the exact size of the data transferred.

Open the website first, then open DevTools. In Chrome, Edge, and other Chromium-based browsers, right-click any element and choose Inspect, or press F12. In Firefox, the process is identical. Navigate to the Network tab before selecting your file. Check the box for Preserve log and clear any existing requests to ensure a clean view.

Now, use the tool. Pick a file and perform the intended action—whether you redact a PDF in the browser or strip EXIF metadata from a photo. Watch the Network panel. If the tool truly processes on-device, you may see ordinary page traffic (like telemetry or font loading), but you should not see your file being transmitted to a remote endpoint.

Pay attention to the request method and size. A file upload typically appears as a POST or PUT request. Inspect the Headers and Payload sections. If the browser is sending multipart/form-data or a binary blob that matches your file size, the data is leaving your device. This is one of the primary risks of online file converters that monetize your data.

What normal network activity looks like

Seeing activity in the Network tab does not always mean a breach of privacy. Browsers load assets like JavaScript, fonts, and WebAssembly (Wasm) modules. Wasm is a high-performance runtime that allows sites to run complex code locally—this is how Privvert tools perform tasks without an upload.

Analytics and telemetry are also common. A page might report a button click or browser version to the developer. While this is a separate privacy concern regarding tracking, it is not the same as a file upload. Privacy is rarely binary; a tool might keep your files local but still track your session. We prefer tools that do neither.

The best test is timing. Load the page, wait for it to finish, clear the Network log, and only then choose your file. If a large outbound request appears immediately after file selection, the tool is likely server-side.

The ultimate test: Go offline

If you want definitive proof, disconnect from the internet and try to use the tool. This is more conclusive than logs. You can use airplane mode or the "Offline" preset in the DevTools Network tab.

If the tool continues to merge PDFs in the browser or compress images locally while offline, the core logic resides on your machine. If the interface hangs, fails, or displays an error about "connecting to server," the tool is not private.

Note: Some pages require an initial connection to fetch certain assets or codec packages. The cleanest test is to load the page, ensure all assets have arrived, then go offline before you ever touch a sensitive file.

Examine request sizes and hidden uploads

Some tools do not upload the file immediately. They wait until you click a final action button like "Convert" or "Export." You must run the entire workflow while monitoring DevTools to be certain. A site might generate a local preview but still upload the full-resolution file during the final save.

Size is the hardest thing to hide. If you are processing a 10 MB document and see a 10 MB POST request, your data has been sent. If you only see tiny requests measured in bytes or kilobytes, those are likely pings or configuration fetches. Remember that EXIF and GPS metadata on photos can be harvested even if a site only uploads a thumbnail.

Hardware signals and red flags

On-device processing puts the work on your hardware. If you extract text from images in the browser and your CPU usage spikes or your laptop fan spins up, that is a sign of local computation. Conversely, if a massive file processes "instantly" on a slow device with zero CPU load, a remote server likely did the heavy lifting.

Be skeptical of the following red flags:

• The page requires an account or "sign-in with Google" to perform a simple task.
• The tool fails immediately when you lose internet access.
• The site uses vague headers like /api/task but hides the payload size.
• The privacy policy is written in marketing generalities like "bank-grade security" instead of technical specifics.

At Privvert, we believe privacy claims should survive inspection. When a tool asks for your data, treat it as a security event. Open DevTools, check the traffic, and require the site to prove it respects your perimeter before you provide your files.