Why these tools run in your browser

The usual shape of a file tool

The conventional design for a web-based file utility is straightforward. The page gives you a file input, the browser posts the bytes to an endpoint, a worker process on the server runs a command-line program such as Ghostscript or ImageMagick, and the result is written to object storage. You are then handed a download link, usually one that expires.

That architecture is popular because it is easy to build and easy to scale horizontally. It also has consequences that are rarely spelled out on the page. Your file now exists on at least one machine you do not control. It may be replicated, backed up, scanned by the platform, or retained in a log. Deletion becomes a policy promise rather than a physical fact, and you have no way to audit it.

For a holiday photo that hardly matters. For a signed contract, a payroll spreadsheet, a medical letter or an unpublished manuscript, it matters a great deal — and those are exactly the documents people need to merge, split or convert.

What local processing actually means

Every file tool in Toolspike reads your file with the File API, works on the resulting ArrayBuffer inside the tab, and hands the output back as a Blob. There is no upload step because there is no endpoint to upload to. The bytes never enter a request body.

This is not a privacy policy that you have to take on trust. It is an architectural property you can observe. Open your browser developer tools, switch to the Network panel, and run a conversion. You will see the page assets, a small request that sends only the tool’s name to check your free run and, on first use of a given tool, the JavaScript bundle for the library it needs. You will not see a request carrying your file. A blunter version of the same test: load the tool page, disconnect from the network, then process a file. It still works.

The browser APIs that make it possible

Four capabilities do most of the work. The File and Blob interfaces give direct access to bytes selected from disk or dropped onto the page. The canvas element, together with createImageBitmap and toBlob, provides hardware-accelerated decoding, scaling and re-encoding for images. WebAssembly lets libraries originally written in C or C++ run at close to native speed. Web Workers move that work off the main thread so the interface keeps responding while a large document is processed.

The libraries layered on top are ordinary open-source packages: pdf-lib for reading and rewriting PDF structure, PDF.js for rasterising pages, SheetJS for spreadsheet formats, and the platform Web Crypto API for hashing. None of them require a server component.

The trade-offs we accept

Local processing is not free. The clearest limit is memory. A server can stream a two-gigabyte PDF through a fixed-size buffer; a browser tab generally cannot. When a file is large enough, the tab runs out of memory and the operation fails. That ceiling depends on your device, your browser and how many other tabs are open, which is why we describe limits in terms of what your machine can hold rather than a number we can promise.

Speed is the second trade-off. Work happens on your CPU, not on a rented one. On a recent laptop this is usually faster overall, because nothing has to travel over the network twice. On an older phone, a heavy job will be noticeably slower than a server would be.

The third is capability. Some transformations genuinely depend on large native toolchains, extensive font libraries or licensed codecs that are impractical to ship to a browser. Where that applies, the honest answer is that the tool does not exist here rather than that it silently uploads.

Finally, there is no history. Because nothing is stored, there is no list of previous conversions, no link to share with a colleague and no way to resume on another device. That is the direct consequence of the same decision that keeps your file private.

Loading only what a job needs

Running libraries in the browser creates a temptation to bundle everything into one download. A PDF renderer, a spreadsheet parser and a LaTeX typesetter together weigh far more than a page of HTML, and forcing every visitor to fetch all of them would make the site slow for people who only wanted to generate a password.

Each tool therefore imports its dependencies dynamically, at the moment the tool is opened. Browsing the catalogue costs you nothing beyond the page itself. Opening the LaTeX editor fetches the typesetting engine; opening the QR generator does not. Once fetched, the module is cached by the browser for subsequent visits.

How to judge any tool that handles your files

The test is the same regardless of who built the tool. Watch the network while it works. Read the retention wording and check whether it describes a physical impossibility or a policy. Ask whether the page needs an account, because an account implies a server that already knows something about you.

Local-first processing is not the right answer to every problem. It is the right answer to this one: a small, sharp utility that takes a file, changes it, and gives it straight back.