How to Verify If an Online Tool Actually Processes Files Locally

A practical, step-by-step guide to using browser DevTools to verify whether an online file converter actually processes your files locally or secretly uploads them to a server. Includes a printable checklist and real-world examples.

Published April 4, 2026 · Updated April 4, 2026

Every time you drag a file into an online converter, you are making a trust decision. You are trusting that the tool does what it claims — especially when it claims your files "never leave your device." But how do you actually verify that? Marketing pages can say whatever they want. Privacy policies can be vague or misleading. The only way to know for certain is to look at the network traffic yourself.

The good news is that every modern browser ships with powerful developer tools that make this straightforward. You do not need to be a software engineer. You need about five minutes and a willingness to open a panel you may not have used before. This guide will walk you through the entire process, explain what to look for, and give you a checklist you can apply to any online tool.

Why This Matters

The difference between local processing and server-side processing is not academic. When a tool uploads your files to a remote server, several things happen that you may not want:

Your files exist on someone else's infrastructure, even if only temporarily. Server logs may record metadata about your files — filenames, sizes, timestamps, IP addresses. If the server is compromised, your files could be exposed. And depending on the jurisdiction, the service provider may be legally required to retain or disclose your data under certain circumstances.

For personal photos, financial documents, medical records, legal files, or anything confidential, the distinction between "processed on your device" and "processed on our servers" is the distinction between privacy and exposure.

Many tools are genuinely transparent about their architecture. But many are not. Some use hybrid approaches where small files are processed locally but large files are silently uploaded. Others process locally for free tiers but server-side for premium features. The only reliable way to know is to check.

Step 1: Open the Network Tab in DevTools

Every major browser includes developer tools with a Network monitor. Here is how to access it:

Chrome, Edge, or Brave

Press F12 or Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (Mac). Click the Network tab at the top of the DevTools panel.

Firefox

Press F12 or Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (Mac). Click the Network tab.

Safari

First enable DevTools: go to Safari > Settings > Advanced and check "Show Develop menu in menu bar." Then press Cmd+Option+I and click the Network tab.

Once the Network tab is open, you will see a timeline and a list that is probably already populated with requests from loading the page. Before you proceed, click the clear button (a circle with a line through it) to start fresh. Also make sure the recording indicator is active — it should be a red dot, meaning network activity is being captured.

Step 2: Run a Conversion and Watch

Now use the online tool as you normally would. Drop in a file, select your output format, and click convert. While the conversion runs, watch the Network tab carefully.

What You Are Looking For

Outbound requests with large payloads. If the tool uploads your file, you will see one or more requests — typically POST or PUT — with a request payload roughly matching your file's size. Click on any suspicious request and look at the Headers tab to see the URL it was sent to, and the Payload or Request tab to see the data size.

WebSocket connections sending binary data. Some tools use WebSocket connections instead of HTTP requests to stream file data to a server. In the Network tab, filter by "WS" to see WebSocket connections. Click on one and look at the Messages tab — if you see large binary frames being sent during conversion, your file is being transmitted.

Requests to domains that are not the tool's own domain. Watch for requests to cloud storage services (amazonaws.com, storage.googleapis.com, cloudinary.com, etc.) or unfamiliar API endpoints. These are strong indicators that your file is being sent elsewhere for processing.

What Silence Looks Like

If the tool genuinely processes files locally, the Network tab will be remarkably quiet during conversion. You may see:

  • Small analytics pings (to google-analytics.com or similar) — these do not contain your file data
  • Requests for JavaScript or WASM files that the tool needs to do the conversion — these are the tool downloading code, not uploading your data
  • Absolutely nothing — the conversion runs entirely with code already loaded in the browser

The key metric is simple: look at the total data transferred (uploaded) during the conversion. If you converted a 5 MB photo and the upload column shows 5 MB or more sent to a remote server, your file was uploaded. If the upload column shows near zero (just small analytics or API calls), the processing was local.

Step 3: Check for Web Workers and WASM Modules

Local processing tools typically use specific browser technologies that you can identify:

WebAssembly (WASM)

Tools that do heavy computation locally — video conversion, PDF manipulation, image processing — often load WebAssembly modules. In the Network tab, look for files with .wasm extensions being downloaded when you first use the tool. Common examples include ffmpeg-core.wasm (for video/audio processing) or similar binary modules. These files are the tool downloading the conversion engine to run on your machine.

Web Workers

Open the Sources tab in DevTools and look for a "Workers" section in the left sidebar (in Chrome) or check the Application tab under "Service Workers." Web Workers run JavaScript in background threads and are a common pattern for local file processing because they prevent the conversion from freezing the browser UI.

Canvas and Blob URLs

Image conversion tools often use the HTML Canvas API. You may see blob: URLs appearing in the Network tab — these are local object references that exist only in your browser's memory. Blob URLs are a strong indicator of local processing because they represent data that was created in the browser, not fetched from a server.

Red Flags: Signs of Server-Side Processing

Beyond the Network tab, several other indicators suggest a tool is sending your files to a remote server:

Upload progress bars that reflect real network transfer. If you see a progress bar that advances at a speed correlated with your internet connection (slow on slow connections, fast on fast connections), the tool is likely uploading. A locally processing tool's progress bar would reflect CPU/memory speed, not bandwidth.

Processing times that vary with your internet speed. If converting the same file takes 10 seconds on fast Wi-Fi but 60 seconds on a slow mobile connection, network transfer is involved.

Terms of service or privacy policies that mention "cloud processing," "server-side rendering," or "temporary storage." Read the fine print. Some tools are honest about uploading files but bury the disclosure in legal text.

File size limits that seem arbitrary. A tool that processes locally is limited by your device's RAM and CPU. A tool that uploads is limited by server costs. If a tool says "files up to 100 MB free, larger files require a premium plan," the limit is probably server-related.

The tool works without JavaScript enabled. If you disable JavaScript in your browser and the tool still converts files (via a traditional form submission), it is definitely server-side. Local processing requires JavaScript.

Green Flags: Signs of Genuine Local Processing

WASM module downloads on first use. Large .wasm files (often several MB) downloading the first time you use a tool indicate it is loading a compiled conversion engine to run locally.

Instant conversion of small files. If a 100 KB image converts in under a second with zero network activity, it is local.

The tool works offline. Some locally processing tools work without an internet connection after the initial page load. Try enabling airplane mode after loading the tool and running a conversion. If it works, the processing is definitively local.

Open source code. If the tool's source code is publicly available, you can verify exactly what it does. This is the gold standard for trust.

Service Worker caching. If the tool registers a Service Worker (check the Application tab in DevTools), it may be caching its conversion engine for offline use — another strong indicator of local architecture.

The Practical Checklist

Use this checklist when evaluating any online file tool:

  1. Open DevTools Network tab before using the tool. Clear existing requests.
  2. Convert a file and watch for large outbound requests (POST/PUT with file-sized payloads).
  3. Check the uploaded data total. Near zero = local. Matches file size = server upload.
  4. Filter for WebSocket connections and check for large binary frames being sent.
  5. Look for .wasm files being downloaded — this indicates local processing engines.
  6. Try converting with airplane mode after the page loads. If it works, it is local.
  7. Read the privacy policy for mentions of cloud processing, temporary storage, or third-party processing.
  8. Check file size limits. Limits based on subscription tiers often indicate server processing costs.
  9. Compare processing speed on fast vs. slow internet. If speed correlates with bandwidth, uploading is involved.
  10. Look at the Sources tab for Web Workers — local tools often offload processing to background threads.

Testing Fileza.io as an Example

If you want to practice with a tool you can trust, try this exercise with Fileza.io. Open DevTools, switch to the Network tab, and clear all requests. Then convert an image — say, a HEIC photo to JPG using the Image Tools page.

Watch the Network tab during conversion. You will see that the only network activity consists of small analytics events and possibly the initial download of WASM modules (like FFmpeg) if this is your first conversion. The actual file data — your photo — never appears in any outbound request. The conversion happens entirely through Canvas API operations and WebAssembly execution in your browser.

This is what genuine local processing looks like in practice. Zero file data uploaded. Zero server roundtrips. Your photo stays on your device from start to finish.

Beyond DevTools: Other Verification Approaches

For users who want to go deeper, a few additional techniques exist:

Browser extensions like uBlock Origin can show blocked requests and give you a secondary view of network activity. Some privacy-focused extensions will flag requests to known cloud processing endpoints.

The Performance tab in DevTools shows CPU utilization during conversion. A locally processing tool will spike your CPU. A tool that uploads and waits for a server response will show minimal local CPU activity during the processing phase.

Wireshark or similar packet capture tools give you a complete, unfiltered view of all network traffic from your device. This is overkill for most people, but it is the most thorough verification method available.

Why Local Processing Is Worth Seeking Out

The effort to verify local processing is worth it because the privacy benefits compound over time. Every file you convert locally is a file that never existed on someone else's server. There is no data breach risk, no retention policy to worry about, no third-party access to consider.

Local processing also tends to be faster for small and medium files because there is no upload/download latency. And it works in situations where server-based tools fail — on airplanes, in areas with poor connectivity, or behind restrictive firewalls.

The browser has become a remarkably capable processing environment. Technologies like WebAssembly, Web Workers, the Canvas API, and the File API mean that almost any file conversion that used to require a server can now run entirely on your device. The tools that take advantage of this architecture are the ones that respect your privacy by design, not just by policy.

The next time a tool claims your files never leave your device, you now have the skills to verify that claim in under five minutes. Trust, but verify.

Sources

  1. Chrome DevTools Network Reference — Google Developers documentation on using the Network panel to monitor HTTP and WebSocket traffic.
  2. MDN Web Docs: WebAssembly — Mozilla's documentation on WebAssembly, how it works in browsers, and its role in client-side computation.
  3. MDN Web Docs: Web Workers API — Mozilla's reference on Web Workers for running scripts in background threads.
  4. W3C File API Specification — The formal specification for client-side file access in web browsers.
  5. Web.dev: "Why Web Workers?" — Google's guide to using Web Workers for performance-sensitive browser applications.