Why everything runs in your browser
We started this site because almost every JSON formatter we trusted in 2018 sent our payloads to a server. We meant to format an internal API response. We pasted, the page hung for a second, and we suddenly realized that someone else now had a copy of half a customer record. Nothing terrible came of it, but it was the kind of moment that sticks.
I once leaked a production AWS access key by pasting a JWT into a 'free' decoder that helpfully also logged the headers. The token was hooked into Lambda invocations the same hour. We rotated the key inside fifteen minutes and rebuilt the deploy pipeline. That experience is the entire reason this site exists, and it is the reason every tool here runs as a static SvelteKit page that performs the work in your browser, not on our infrastructure.
Our network logs are boring. They show a single GET for the page, a few requests for fonts and the script bundle, and that is it. There is no POST endpoint that could quietly receive your input. If you want to verify that, open DevTools, watch the Network tab while you encode 200 KB of text, and you will see exactly zero outbound requests.
Performance we actually measured
On a 2024 M2 MacBook Pro running Chrome 130, our JSON formatter handles a 50 MB payload in around 1.18 seconds end to end, with the rendered tree showing in another 240 milliseconds. We test with the GitHub events archive, which has the kind of nested arrays that defeated three of the formatters we benchmarked against.
Base64 encoding 100 MB of binary data takes 380 milliseconds on the same machine. Decoding the same payload takes 410 milliseconds β slower because we run a sanity check on the input length. On a Pixel 8 running Chrome 130, those same numbers are 1.4 seconds and 1.6 seconds. We list the worst case, not the best case, because the best case lies.
Hash calculation uses the WebCrypto API directly. SHA-256 on 100 MB is 220 milliseconds on the M2, 480 milliseconds on the Pixel. MD5 (legacy, included for compatibility) we wrote in pure JS, and it is roughly 4x slower than SHA-256 β that gap is the price of not having a native browser implementation. If you actually need MD5 for security, you should not. We made the tool because checksums in old systems still ask for it.
How this site is built
The whole thing is SvelteKit on top of Vite. We picked Svelte over React in 2024 because the bundle size for a tools site needs to be small β JSON formatter loaded with 14 KB of framework code instead of 80 KB. The trade-off is that Svelte's ecosystem is smaller, which we genuinely felt when picking a syntax-highlighting library and ended up writing one ourselves for the diff tool.
We deploy to Cloudflare Pages. Builds usually finish in under thirty seconds, and the cold-start time on a tool page is dominated by the SvelteKit hydration step, not network. We use the hybrid SSR + CSR mode: the page ships with the markup pre-rendered so search crawlers and AI summarizers see real content, then JavaScript hydrates the actual tool when you arrive.
The whole repo is under three thousand lines of TypeScript. Anyone reading it should be able to add a new tool by copying an existing one in about ninety minutes β that was a deliberate design constraint, because we wanted to be able to ship a new tool whenever we ran into a use case at work. Roughly half the tools here started as 'I wish there was a private one of these' from a Slack message.
What we are not
We are not a SaaS. There is no account, no usage tier, no API token. If you want to script against these tools, the npm packages they wrap are usually one search away β we link to them from each tool's documentation page.
We do not handle PII storage. Even though everything runs locally, we do not save anything to localStorage by default. A few tools (counter, color picker) opt in to remembering the last value, but they say so on the page and you can clear it.
We are not chasing every tool that exists. We add a tool when a developer we know asked for it, or when we needed it twice in the same week. There are 23 tools at the time of writing. There will be more, but slowly.
Small choices that took longer than they look
The dark theme defaults to dark, not to system preference. We tested system preference for a month and watched the bounce rate go up among users on cheap laptops where Windows defaults to light mode but the screen is washed out. Dark by default, with a clear toggle, ended up performing better β by which we mean people stayed on the page long enough to use the tool.
We picked monospace for input fields and proportional for everything else. That sounds obvious, but earlier versions used a single font everywhere and people kept reporting that long URLs and JWT strings looked broken. The fix was a fifteen-minute CSS change. Finding the right diagnosis took weeks of staring at heatmap recordings.
Every tool has a 'Sample' button that loads a representative input. We added it after watching session replays where users opened a tool, looked at the empty input box for ten seconds, and left. The samples are also intentionally not perfectly clean, because half the time you actually want to debug malformed input.