How do online file tools work without uploading?

Online tools that work without uploading bring the processing code to your browser, then read your file and build the result on your own device. The page downloads things like its interface and processing engines, but it doesn’t send your file’s contents or its name anywhere. This guide explains how that works and how to check it yourself with your browser’s developer tools.

How in-browser processing works

A server-based tool sends your file to a server, and you download the result the server makes. An in-browser tool works the other way around: the processing code comes to your browser. Your file stays on your device, and the page’s code reads it and creates the result right there.

A web page can only read files you hand to it, through a file picker or by drag and drop. Choosing a file doesn’t send it anywhere by itself. To send it, the page’s code would have to make a separate network request, and requests like that show up in developer tools.

Three browser technologies make in-browser processing practical:

Technology	What it does (summarized from MDN)	Where ZEKILO Studio uses it
WebAssembly	Runs programs written in languages like C, C++ and Rust in the browser at near-native speed	Image compression engines (MozJPEG, OxiPNG and others), the MP3 encoder (LAME), the video fallback engine (FFmpeg)
Web Workers	Runs scripts on a background thread, separate from the main thread that handles the page, so the page doesn’t freeze during heavy work	Image, PDF and video processing
WebCodecs	Encodes and decodes video and audio frame by frame with the codecs built into the browser, using hardware acceleration	Compress Video, Convert to MP4, Video to GIF, Video to MP3

The main thread and a worker pass data to each other as messages. That handoff happens inside the same browser, so it isn’t a network request. Merge PDF, for example, runs a JavaScript library called pdf-lib inside a worker.

What the page loads, and what it never sends

Type	What’s included
Loaded: page files	Static files such as HTML, CSS, JavaScript and images that draw the page
Loaded: processing engines	Each tool’s engine is downloaded the first time you use it. If your browser can’t handle a video’s codec, a fallback engine (FFmpeg, about 31 MB) is downloaded the first time and kept in the browser cache
Loaded and sent: ads and analytics	Ad scripts on pages that show ads, and Google’s analytics script. Analytics may record usage information such as the page address, which tool you used, the file format and a rough size range
Never sent	Your file’s contents, its name, its exact size, and the result file

Processing engines come from the same address as the site. Downloading an engine means downloading a program; it doesn’t send your file.

What to look for in the Network panel

These steps use Chrome. Developer tools in other browsers have similar features.

• Opening it: press F12 or Ctrl+Shift+I on Windows, or Cmd+Option+I on Mac, then choose the Network tab. DevTools only logs requests while it’s open, so open it before you choose a file.
• Method column: right-click the header of the requests table to show the Method column. Requests that download files are usually GET, and requests that carry data out show up as POST or a similar method.
• Filter: type method:POST in the filter box to see only POST requests. Click Wasm among the type buttons to see only WebAssembly engine files.
• Payload tab: click a request and open the Payload tab to see what that request sent.
• Size column: this is the size of the response received from the server. A large value doesn’t mean anything was sent.

How to do it with ZEKILO Studio

1. Open Compress Image, open the Network tab in DevTools, and click Clear to empty the list.
2. Pick a photo with [Choose files]. Compress Image starts compressing as soon as you add it. When the result appears, save it with [Download].
3. Check the new requests. You may see requests that download engine files, and analytics requests may show up as POST. Click them and open Payload, and you can confirm they don’t contain your file’s contents or name.

You can check Merge PDF and Compress Video the same way. These two tools start processing only after you add files and press [Start]. If you add a file to Compress Video that needs the fallback engine and press [Start], the progress card shows “Preparing the processing engine · about 31 MB, first time only”, and the first time, a request that downloads the engine file appears in the Network tab.

Limits of in-browser processing

• Device power and memory: processing uses your device’s CPU and memory, so how long it takes depends on your device. Each tool has a recommended file size, and going over it shows a warning. If memory runs out, you may see “Stopped: your device ran out of memory”.
• Browser support: MDN notes that devices and browsers may support only some of the codecs WebCodecs can work with. In a browser that lacks a needed feature, you’ll see “This tool doesn’t work in this browser.”
• First-time download: the fallback engine is large, so if you’re on mobile data, we recommend connecting to Wi-Fi.
• Closing the page: processing happens inside the page, so closing it partway through stops the work.

Summary

• Tools that work without uploading process files in your browser with WebAssembly, Web Workers and WebCodecs.
• The page loads its own files, processing engines, and ad and analytics scripts. It doesn’t send your file’s contents, name or exact size.
• In the DevTools Network tab, the Method column and the Payload tab let you check what goes in and out.
• Processing speed and the largest file you can handle depend on your device and browser.