Under the Hood: How We Built Browser-Side Calculators That Never Phones Home

One of the core promises of Compyrix is that, wherever possible, your data never leaves your browser. A password generator that sends the generated password to a server in plaintext is not a password generator you can trust. A JSON formatter that POSTs your 20-megabyte API payload to a random AWS endpoint is not a JSON formatter you should use for production data. This post is about how we keep that promise, and more importantly, how you can verify that we are keeping it.

At the architectural level, almost every tool on the site is implemented as a pure function written in TypeScript, rendered by React server components that ship only the event handlers to the client, with results computed in the same tab you typed them into. There is no form submission, no fetch, no background beacon, no analytics endpoint that catches your inputs by accident.

The interesting design question is not why we do this — the privacy and speed advantages are obvious — but why it is uncommon enough that it is worth writing a blog post about. The short answer: rendering everything client-side used to mean shipping hundreds of kilobytes of JavaScript before anyone could use the page. Next.js App Router with Server Components, partial hydration, and granular action boundaries changed the trade-off in a big way. We can ship a fully rendered calculator page in roughly 30 kilobytes of HTML, a 15-kilobyte React runtime, and then hydrate only the input handlers and the pure-computation modules.

For the math-heavy tools like the percentage calculator and the BMI calculator, every formula is implemented by hand with extensive property-based tests, and the implementation lives in a standalone package with zero third-party dependencies. That is not because we do not trust npm; it is because for the 12 most common calculations, writing the 2,000 lines of code ourselves, from the published formulas, gives us reproducibility we can audit. No dependency update can silently change a rounding behavior.

How do you, the user, verify any of this? Open your browser DevTools with F12 or Ctrl+Shift+I, go to the Network tab, filter for Fetch/XHR, open any non-AI tool like the Password Generator or the Word Counter, and then type, click, and generate as much as you want. Zero network requests. If you want to be extra thorough, click each input and examine the actual event handler in the Sources or Debugger tab. You will see it call a local function and update the DOM. Nothing leaves the tab.

The one exception, by design, is the AI-powered tools. When you click the Generate button on the YouTube Title Generator or the Paraphrasing tool, we send your prompt to our servers because running a 70-billion-parameter language model in your browser is not yet practical. That request goes directly to the Groq API through our edge function, nothing is logged with your IP or any identifier, and you can see the full JSON payload in the Network tab before it is sent. Nothing is hidden.

If you find any tool — any tool at all — that performs a network request with your inputs when the documentation says it runs client-side, email me directly at sam [at] compyrix [dot] com and I will buy you a coffee, fix the bug, and thank you publicly on the changelog. This stuff matters to us.