How It Works

Every tool on this site follows the same basic shape. There's no account, no upload, and no server in the loop for the actual work — just your browser, doing the same kind of computation a native desktop app would do, using code that was sent to you once when the page loaded.

The four steps

1. You give the tool an input. That's a file dropped onto a drop zone, text pasted into a text area, or numbers typed into a calculator field. This data goes straight into your browser tab's own memory — it is read using standard browser APIs (FileReader, arrayBuffer()) and never leaves that tab.
2. The work happens locally, often on a background thread. For anything heavier than an instant calculation — splitting a PDF, converting an image, compressing a file — the actual processing runs inside a Web Worker, a background thread built into every modern browser. This matters because it keeps the page itself responsive: you can still scroll, cancel, or watch a progress bar update while, say, a 40MB PDF is being split, instead of the tab freezing until the work finishes. Lighter, near-instant operations (basic calculators, small text diffs) skip the worker and just compute directly, since the overhead of spinning up a background thread would be slower than the calculation itself for small inputs.
3. The engine is a real, well-tested library — not a from-scratch reimplementation.Each tool category leans on a purpose-built library that already knows how to correctly parse and rewrite its file format: pdf-lib for editing a PDF's internal structure, the browser's native Canvas API for image conversion and resizing,svgo for SVG optimization, mathjs for calculator expressions, and so on. This is also why fidelity is generally high — splitting a PDF with pdf-libcopies the original page objects directly rather than rasterizing and reassembling them, so text stays selectable and sharp.
4. The result comes back to you, locally. Once processing finishes, the output (a new file, a formatted string, a computed number) is handed back to the page as an in-memory object. For files, that becomes a downloadable link generated withURL.createObjectURL() — or, in browsers that support it, a native "Save As" dialog via the File System Access API. At no point in this chain does the result get sent anywhere either.

What actually leaves your device

For the overwhelming majority of tools: nothing. You can verify this yourself by opening your browser's DevTools Network tab before running a tool — you'll see zero outgoing requests during processing. There is exactly one documented exception: the Currency Converter calculator fetches a public, static exchange-rate snapshot once per session, because live exchange rates can't be computed locally by definition. That fetch carries no information about you or your input. See the Privacy Policy for the full detail on that exception and on what small amount of preference data (like your theme choice) is saved locally in your own browser storage.

Why not just use a server?

A server-side version of these tools would work too, and for some kinds of problems a server is still the right architecture. But for everyday file utilities — splitting a PDF, resizing a photo, reformatting some JSON — asking you to upload potentially sensitive documents to a third party's server is a real trust cost that modern browsers no longer require. Running entirely client-side also means the tools keep working offline once loaded, respond instantly without a network round-trip, and can't leak your data through a server breach, because there is no server that ever holds it.

Curious about a specific tool's internals? Each tool's own page has a "How it works" section with details specific to that tool, plus an FAQ covering common edge cases.