Why we built Stax Tools

If you've ever pasted a JSON blob into a random "JSON formatter" website, paused for a second, and wondered "is this thing storing what I just pasted?" — that's the question Stax was built to answer.

The answer, for everything we ship, is no. Your data never leaves your device. There is no server in the loop. Every tool on stax.tools runs entirely in your browser using JavaScript and Web APIs.

This post is about why that matters, why most tool sites get it wrong, and what we're trying to do differently with 235+ free tools that all share the same constraint.

The accidental data lake problem

Most online "free tool" sites work like this:

You paste your data into a form.
The form posts it to a backend.
The backend processes the data and returns a result.
The site shows you the result.

That's the obvious architecture. It's also the architecture that turns every "free PDF compressor" into a tiny private-data lake. The operator may have the best intentions — they may even promise not to log anything — but the data is still travelling across the public internet, getting decrypted at their backend, sitting in their RAM, and possibly bouncing off intermediate proxies before being deleted.

For most use cases, that's fine. People paste throwaway data into throwaway tools and nobody cares.

For the use cases we care about — formatting JSON that contains an API key, compressing a PDF of your tax return, decoding a JWT that authorises your bank account, calculating an EMI on a loan you haven't signed yet — that's not fine. The "delete it after 1 hour" promise is unverifiable, the third-party AWS bucket might be misconfigured, and the operator might get acquired tomorrow.

What "client-side" actually means

Browsers are very capable computers now. They can:

Parse and validate JSON faster than any server can ship a response.
Compress PNGs and PDFs with WebAssembly modules running locally.
Generate cryptographic hashes (SHA-256, MD5) using SubtleCrypto.
Run regex engines, format SQL, lint code — all without a server round trip.
Read and write files using the File System Access API.

For 235 of the tools we ship, there is no advantage to a server — and several disadvantages: latency, privacy risk, hosting cost, downtime exposure. So we just don't have one. Every tool's "backend" is your browser.

When you paste 50 KB of JSON into our formatter, the formatting happens on your laptop's CPU. When you compress a 10 MB image, your browser's WebAssembly engine does it. The network requests Chrome's DevTools shows during these operations? Just static HTML, CSS, and JavaScript files. Zero data egress. You can verify this yourself in 10 seconds.

Why we shipped 199 of them

Most "privacy-first" tool sites ship two or three flagship utilities. We wanted to see if you could run a comprehensive toolkit — the kind people normally bookmark across 30 different domains — under a single roof, all client-side, all free.

The catalog now spans:

Developer tools — JSON, regex, hashing, encoding, CSS, color, cron, JWT, SQL, HTML, image and PDF processing.
Finance calculators for India — EMI, SIP, GST, take-home salary, PPF, NPS, HRA, retirement.
Health calculators — BMI, body fat, calorie, macro, pregnancy due date.
Engineering calculators — beam, concrete, rebar, brick, ohm's law, resistor color code.
Creator tools — YouTube earnings, thumbnail downloader, hashtag generators.
Career tools — resume builder, invoice generator, email signatures.
AI helpers — prompt builder, token counter, system prompt builder.

Every category, every tool, same rule: runs in your browser, no signup, no server.

What we changed about the standard playbook

Three deliberate departures from how typical online-tool sites work:

1. No "freemium" lock screens. Some operators show a tool, let you generate a result, and then put a paywall in front of the download button. We don't. Every tool's full output is free, every time, no email capture.

2. No tracking of inputs. GA4 and Microsoft Clarity track anonymous usage stats — pageviews, clicks, scroll depth — but never the contents of your forms, files, or text. Our consent banner gates these analytics by default for EU users via Google Consent Mode v2.

3. Translations from day one. Every tool ships in English, Hindi, Spanish, French, and Arabic, with localised FAQ and SEO content. If you visit /json-formatter or /hi/json-formatter or /ar/json-formatter, you get the same tool in your language — not a Google Translate widget.

What's coming next

The 199 tools are the foundation. The product roadmap from here:

Pro tier (planned for Q3 2026) — saved tool history, favourites, dark mode, and ad-free experience for ₹400/month or equivalent. The free tier stays free forever; Pro unlocks ergonomics, never functionality.
Browser extension — open any tool from your address bar, drop files directly into the right tool.
Public API for the 10 most-used tools, with a free tier and a paid Power tier for high-volume users.
Open-sourcing the core utilities — the small WebAssembly modules and TypeScript libraries that power the tools belong on GitHub.

If any of that sounds interesting, the About page has more, and you can always reach us via the contact page.

The tools that were hardest to build client-side

Some tools required significant engineering to run entirely without a server. Here are three that pushed the limits of what browsers can do.

PDF processing was the first real challenge. PDF is a complex binary format, and the JavaScript library ecosystem for it (pdf-lib, PDF.js) is impressive but not complete. Operations like merging large PDFs, handling password-encrypted files, or resampling embedded images require careful memory management to avoid crashes in low-RAM browser environments. We spent more time on PDF tools than on any other category.

Image compression required WebAssembly to hit acceptable performance. JavaScript alone is too slow for compressing large images. We use the browser's native Canvas API for JPEG and WebP output, which is hardware-accelerated on modern devices and produces smaller files than pure-JS codecs. The quality slider controls the Canvas compression parameter directly.

The finance calculators for India required getting the maths right — not just building the UI. EMI calculations with different interest compounding methods, PPF with annual compounding but monthly contributions, NPS with tier-1 and tier-2 accounts, income tax with the new regime's slabs and the old regime's deductions — each has nuances that popular calculator sites get wrong. We cross-referenced against government publications and verified against chartered accountant inputs.

Why the India finance category matters most

India has one of the fastest-growing populations of first-time investors. SIPs, PPF, NPS, ELSS — these are genuinely complex products. The people who use these calculators are often making real financial decisions: whether to switch tax regimes, how much to invest monthly to reach a retirement corpus, whether to prepay a home loan or invest the surplus.

Getting these numbers wrong isn't just an accuracy failure — it's a trust failure. We check every Indian tax and finance calculator against the official SEBI, RBI, and income tax department guidelines at the time of publication, and update them when rules change (new tax slabs, revised PPF rates, NPS changes).

If you use our Income Tax Calculator, EMI Calculator, or PPF Calculator and find an error, the contact page email goes directly to the founder — not a support queue.

The privacy architecture in practice

The client-side constraint forces a specific technical architecture that is worth understanding if you're a developer.

Every tool is a React component that receives user input, processes it entirely within the component using browser APIs and JavaScript, and renders output. There is no fetch() or XMLHttpRequest call in any tool component (except the AI features, which are clearly labelled). The state management is local (React state or useReducer), with no central backend state.

The site is statically generated with Next.js. Every tool page is a pre-rendered HTML file. When you visit /json-formatter, you receive a complete HTML document — no server-rendered dynamic content. The JavaScript that runs the tool is loaded as a static asset from our CDN.

This architecture has a useful side effect: the site works offline after the first load. If you've visited a tool before and lose internet connection, the tool still works — your browser has all the JavaScript it needs cached locally.

What we're learning from building this

A few things have surprised us along the way.

People really do read privacy policies when something is at stake. Our privacy policy gets more traffic than most of our blog posts. When people are about to paste a JWT or a tax document into a tool, they check.

The India-language audience is underserved by privacy tools. Providing Hindi, and eventually more Indian regional languages, isn't just a localisation feature — it's about making the privacy conversation accessible to people who don't primarily read English.

Calculator accuracy matters more than UI elegance. Tools with minor inaccuracies generate much more negative feedback than tools with plain-looking interfaces. Users can spot a wrong EMI calculation instantly because they're comparing against their bank statement.

What's coming next

The 235+ tools are the foundation. The product roadmap from here:

Pro tier (planned for Q3 2026) — saved tool history, favourites, dark mode, and ad-free experience for ₹400/month or equivalent. The free tier stays free forever; Pro unlocks ergonomics, never functionality.
Browser extension — open any tool from your address bar, drop files directly into the right tool.
Public API for the 10 most-used tools, with a free tier and a paid Power tier for high-volume users.
Open-sourcing the core utilities — the small WebAssembly modules and TypeScript libraries that power the tools belong on GitHub.

If any of that sounds interesting, the About page has more, and you can always reach us via the contact page.

— Built in 2026, in Ahmedabad.