Why We Run Everything in Your Browser

Every calculation on this site happens in your browser. Nothing you type, and no file you select, is transmitted to us. This is worth explaining properly, because "we respect your privacy" is something every site says and almost none of them let you check.

What client-side actually means

A conventional online tool works like this: your browser sends data to a server, the server computes a result, the server sends it back. Between those steps your data exists on someone else’s machine, subject to their logging, their retention policy, their backup regime and their breach history.

These tools work differently. The JavaScript that performs the calculation is downloaded with the page and runs on your device. There is no second step. When you enter a salary into a tax calculator or select a PDF to compress, that data never crosses the network.

The distinction is architectural, not a policy. A policy can change without notice. An architecture with no server-side endpoint cannot start receiving your data without a visible code change.

How to check, in ten seconds

Do not take our word for it. Two methods:

The network tab. Press F12, open the Network panel, and use any tool. You will see the initial page load (HTML, CSS, JavaScript, fonts), and then nothing. No POST requests. No XHR carrying your values.

The disconnect test. Load a tool page, then turn off your Wi-Fi. Keep using the tool. It works. A tool that computes on a server cannot do this, so the fact that it keeps working is proof the computation is local.

This second test is the one we would suggest, because it requires no technical knowledge and cannot be faked.

How it is possible

Browsers have become capable enough that most of what used to need a server no longer does.

• Every calculator here is a JavaScript function. Loans, BMI, unit conversions and statistics were never operations that needed a data centre.
• The Web Crypto API provides SHA-256, SHA-512, AES and secure random number generation natively. It is the same implementation the browser uses for HTTPS.
• The Canvas API decodes, resizes, re-encodes and converts images between formats. The File API reads a selected file into memory without uploading it.
• For PDFs, pdf.js renders pages and pdf-lib manipulates document structure, both compiled to run in the browser. PDF encryption uses qpdf compiled to WebAssembly.
• Regular expressions, encoding conversions, formatters and validators for text are all built in.

WebAssembly is the piece that changed the calculus. Libraries written in C or C++ can be compiled to run in a browser tab at close to native speed, which brought a whole category of file-processing tools within reach of client-side implementation.

What it costs us

This is a real constraint and it has consequences we would rather be honest about.

We cannot build certain tools at all. Anything requiring live external data (currency rates, stock quotes, WHOIS records, genuine backlink indexes, IP geolocation) needs a server. Those tools do not exist here. That is a gap in our catalogue, and it is deliberate.

Large files depend on your hardware. A 200 MB PDF is processed using your machine’s memory and CPU. On a modern laptop this is fine; on an older phone it may be slow or fail. A server-side tool would perform identically for everyone. We think the trade is worth it, but it is a trade.

Initial page load is larger. Sending you the code to do the work means sending more code. We keep libraries local rather than pulling from a CDN (no third party sees your requests), and load each tool’s dependencies only on the page that needs them.

We learn almost nothing. We cannot see which inputs people use, which calculations fail, or where a tool confuses people. Analytics tells us a page was viewed. It cannot tell us what was computed on it, because we genuinely do not have that information.

On advertising

The site is funded by advertising, and it would be dishonest not to address that directly.

Ads are served by Google AdSense, which is a third party and does set cookies. That is separate from the tools themselves and does not give anyone access to what you type. We implement Consent Mode v2, so visitors in the EEA and UK are asked before any advertising or analytics cookie is set, and everything stays denied until they choose.

We use Google Analytics to count page views. It records that a page was loaded. It does not and cannot record the contents of a form field on that page, because those values never leave your device to begin with.

If you would rather have neither, reject non-essential cookies in the banner. Every tool works identically.

Why we built it this way

Mostly because of the specific things people put into tools like these.

A salary, into a tax calculator. A medical measurement, into a BMI or dosage tool. A password, into a strength checker. An employment contract, into a PDF merger. An API response containing customer records, into a JSON formatter.

Every one of those is information a reasonable person would not email to a stranger, and uploading it to an unfamiliar web service is materially the same act. The uncomfortable part is that most people do it without noticing, because the interface does not look like a transfer.

Building client-side removes the question. There is no retention policy to trust, no breach that could expose your inputs, and no jurisdiction question about where a server sits, because there is no server holding anything.

It is not a complete privacy story. We still have web server logs with IP addresses, like every site. We still serve third-party ads. But on the specific matter of what you type into a tool, the guarantee is structural, and you can verify it yourself in less time than it took to read this paragraph.