Processing files in the browser vs uploading to a server: what actually differs

The difference is where the program runs

With an upload-based tool, the file you choose travels over the internet to the company's computer (a server). The merging, compressing or whatever else happens there, and you download the result. The program lives on the server; your computer just sends and receives files.

With browser-based processing it's the other way around: the program comes down to your browser along with the web page. When you choose a file, the browser reads it into your computer's memory, the downloaded program does the work right there, and the result is saved directly. The file's contents never leave your device.

On screen both look the same, "put a file into a website and get a result", so they're hard to tell apart. The difference isn't in what you see but in what travels over the network.

Why browsers can do this now

Web pages used to do little more than display documents, but today's browsers include the building blocks for running real programs. ToolyStation's tools are built from these.

• Reading files: the browser can read the contents of files the user explicitly chooses, and only those. A page can't open other files on your computer on its own.
• Canvas: a drawing surface for painting, compositing and re-saving images as JPEG or PNG. Used for watermarking, Images to PDF and PDF compression.
• WebAssembly and graphics computation: ways to run heavy calculations fast. Hand tracking (MediaPipe) runs on WebAssembly, and the facial expression models compute using the graphics processor.
• Web Audio: generating sound and analyzing music files. Used to play beats and to detect BPM.

What actually travels over the network on this site

"Your files aren't sent to a server" doesn't mean "the internet isn't used at all". Broken down precisely:

• Pages and programs: the web page itself and the program files the tools need come from the site's server (Cloudflare).
• External libraries and models: part of pdf.js comes from unpkg.com, and the face and hand recognition models come from cdn.jsdelivr.net. These requests fetch program and model files; your own files aren't sent with them. The servers receiving the requests can see standard connection details such as IP address and browser type.
• Ads: the site shows Google AdSense ads, so ad scripts and cookies run. Ad scripts can send page-visit information to Google, but they aren't there to read or send the contents of files you put into a tool.
• Your files and camera video: these alone are never transmitted. Reading, processing and saving all finish inside the browser.

External requests also vary by tool. Images to PDF, Batch Watermark, BPM Tapper, Tempo Ear Test and BPM Detector fetch no further external libraries once the page has loaded. Merge and Compress PDF fetch part of pdf.js, and the emotion, first-impression, animal-face and gesture tools fetch recognition models from public CDNs.

How to check for yourself

You don't have to take anyone's word for it. A desktop browser's developer tools show every request. These steps are for Chrome and Edge.

1. With a tool page open, press F12 (Option+⌘+I on a Mac) to open developer tools and choose the Network tab.
2. Click the clear button (🚫) above the list to empty it.
3. Add a file to the tool and run the job to completion.
4. Look at the new requests. Each shows an address and size, so check whether any request sends out data about the size of your file (usually a large request with method POST).

There's an even simpler test. Tools that don't use external libraries, such as Images to PDF, keep working if you disconnect from the internet after the page has loaded. If the PDF is still created while you're offline, the file can't have gone through a server.

Phone browsers don't have developer tools, so that method is hard to use there. Instead, open the tool page, switch on airplane mode and run the job. If a tool that needs no external libraries still produces its result, no internet connection was used for that job. Turn airplane mode off again when you're done.

Advantages of browser-based processing

• File contents stay on your device. That makes it easier to use for things you'd rather not leave on someone else's server, such as contracts, ID copies and personal photos.
• No upload wait. With a server, large files take time to upload and download; in the browser that step disappears. Processing time depends on your device instead.
• There's no file retention or deletion policy to check, because nothing is stored. Closing the tab clears what was in memory.

Limitations of browser-based processing

• It depends on your device. A PDF of hundreds of megabytes or dozens of high-resolution photos can be slow or run out of memory on an older laptop or phone. Servers can usually draw on more memory and computing power.
• Some jobs are out of reach. Converting Hancom (HWP) documents to PDF, or OCR that reads text out of scans, needs heavy or specialized software and may be impractical or lower quality in a browser alone.
• Work isn't saved. Continuing on another device or downloading the result again later requires a server.
• Programs and models download on first use. Large files like recognition models can take a while to start on a slow connection.
• Battery and heat: since your device does the computing, tools that continuously analyze camera video or jobs on large files can drain a laptop or phone battery quickly and make it warm.
• Results can differ slightly between browsers. Depending on the formats (such as HEIC photos) and features a browser supports, the same job may work in one and not another.

When a server-based tool is the better fit

Browser processing isn't always best. A server-based service may suit you better when:

• You need to process very large files or big batches and your device isn't up to it
• The job needs specialized software, such as document format conversion or OCR
• Several people need to view and edit the same file, or results must be kept in the cloud

If you use an upload-based service, check its privacy policy for how long uploaded files are kept, when they're deleted, and whether they're used for anything else, such as improving the service. For sensitive files, it's safest to check this before uploading.

Things to watch even with browser processing

• Shared computers: results are saved to the downloads folder. On a library, school or internet-café computer, delete downloaded files when you're done.
• Browser extensions: an extension with permission to read all websites can also access what's shown on the page. When handling sensitive files, remove extensions you don't recognize or use a private window where extensions are off.
• Screen sharing and recording: if you're sharing your screen in a video call, file contents shown in a preview are visible to others.
• Camera tools: switch the camera off or close the tab when you're finished. The camera icon in the address bar shows whether it's still on.

Common misconceptions

• "If the address is https, uploading is safe": https encrypts the file while it travels so nobody in between can read it. It says nothing about how the file is stored or used once it reaches the server; for that you need the service's policy.
• "Browser processing leaves no trace": file contents don't stay on a server, but your device keeps browsing history, downloaded results, and the site's cookies and stored data. If you'd rather leave no trace, use a private window and tidy up your downloads.
• "Free services use your uploaded files elsewhere": you can't generalize. Some free services delete files immediately, and some paid ones keep them for a while. Judge by the published policy, not the price.
• "Browser-based tools all work offline": tools that need external libraries or models must download them first, so they need a connection. Whether a tool works fully offline varies from tool to tool.

Summing up: which to choose

The rule of thumb is simple. If the file is sensitive and the job is fairly light (merging a few PDFs, watermarking a few dozen photos), browser processing involves less risk. If the file is very large, needs specialist conversion, or the result must live in the cloud, a server-based tool may fit better; just check its retention and deletion policy first.

Either way, keeping your important originals separately and opening the result to check it before you submit is the most reliable safeguard of all.