Browser first: the one rule behind every tool on KitDev Space

Hamed — Sun, 06 Sep 2026 22:30:42 +0000

A while ago I caught myself pasting a JWT from a production API into the first "JWT decoder" Google gave me. I wanted to read the claims. I didn't stop to think about where the token went, and honestly, neither does anyone else. We do the same with .env files in JSON converters and with photos in EXIF strippers. The site has a privacy policy that says the server keeps nothing, and we take its word for it.

That moment is roughly why KitDev Space exists. I wanted a set of everyday developer tools where I didn't have to take anyone's word for it, including my own. The way I got there was less about the tools and more about one rule I wrote down early and then refused to bend. This post is about that rule.

The rule

Run the work in the browser. Use a server only when the browser genuinely can't do the job.

The first half is easy to agree with. The second half is where it gets interesting, because "can't" has to mean something concrete or every tool ends up on the server for convenience. So I wrote down the situations that actually qualify, and the list ended up shorter than I expected:

The work needs a native library. Encoding AVIF or rasterizing an SVG needs a real image codec. Opening a TLS handshake needs a socket.
The work needs to talk to another host. DNS records, HTTP headers, RDAP, OpenGraph previews. The browser can't make those requests because of CORS, and it shouldn't be able to.
The work needs a runtime API with no browser equivalent, like Bun.dns or Bun.Archive.
The input is too large for a browser tab to hold comfortably.

If a tool doesn't hit one of those, it stays in the browser. I've been tempted to make exceptions a few times, usually when the server version would have been twenty lines and the browser version two hundred. I haven't yet.

The browser does more than I gave it credit for

Going in, I assumed I'd be writing a lot of server code. I was wrong about that. Most of what a developer tool site does is already covered by platform APIs or by a small dependency that runs fine in a tab.

Work	What handles it in the browser
SHA-1, SHA-256, SHA-384, SHA-512	`crypto.subtle.digest`
Random bytes, UUIDs	`crypto.getRandomValues`
AES-256-GCM, PBKDF2, HMAC	`crypto.subtle`
Resize, rotate, crop	`OffscreenCanvas`, `createImageBitmap`
JPEG, PNG, WebP encode	`OffscreenCanvas.convertToBlob`
Reading EXIF and GPS metadata	a `DataView` over the file bytes
Gzip, deflate, tar	`fflate`
YAML, TOML, JSONC, JSON5	`confbox`
SQLite	`sql.js` (WebAssembly)

So the JWT debugger verifies HS256 signatures with Web Crypto and never sees a server. The AES tool derives its key with PBKDF2 in your tab. The tar explorer opens an archive without uploading it. The SQLite studio runs an actual database in memory. None of that required anything clever, just a willingness to check what the platform already had before reaching for a route.

Web Crypto does have gaps. There's no MD5, no CRC32, no xxHash. I could have pulled in a JavaScript MD5 library and kept everything client side, but the hash tool also offers xxhash64 and wyhash, and shipping all of that to the browser for algorithms most people rarely use felt wrong. So the hash generator keeps a server path for those, and the page says so in plain words when you pick one. I'd rather tell you which option leaves your machine than pretend nothing does.

One module, two paths

A tool with both a browser path and a server path is a maintenance trap waiting to happen. Two implementations, one of them quietly drifts, and now the same input gives different output depending on where it ran. I got bitten by exactly this on the data converter early on.

The fix I settled on: each shared module exports the function that does the work plus a small guard that answers "can this run here?". The page checks the guard. The server route imports the same module. The code that actually hashes a file exists once.

// shared/utils/crypto/hash.ts
const SUBTLE_NAMES = {
  sha1: 'SHA-1',
  sha256: 'SHA-256',
  sha384: 'SHA-384',
  sha512: 'SHA-512'
}

export function canHashInBrowser(algorithm: HashAlgorithm): boolean {
  return algorithm in SUBTLE_NAMES
}

// simplified page logic
const result = canHashInBrowser(algorithm)
  ? await hashInBrowser(input, algorithm)
  : await $fetch('/api/hash', { method: 'POST', body: { input, algorithm } })

Hashing, data format conversion, code formatting and semver all use this shape now. When a new tool needs both paths, it gets the same treatment, and I don't have to think about it anymore.

What the server is actually for

The tools that do need a server run on Bun. Each one is there because of one of the four reasons above, and I can tell you which:

The TLS Certificate Inspector opens a socket and reads the chain, the SANs and the cipher suite.
DNS Lookup and the Email Health Inspector query A, MX, TXT, SPF, DKIM and DMARC records.
The HTTP Inspector, OpenGraph Previewer and RDAP Lookup all fetch from a third-party host.
Image Studio and the Favicon Set Generator use Bun.Image for AVIF and ICO output.
The TS/JSX Transpiler and the AST Playground run OXC, which is native code.

Because every server route is a liability, they all go through the same checklist before they ship. Validate the URL and allow only http and https. Block localhost, private ranges, link-local, cloud metadata hosts, and the IPv6 transition ranges that smuggle an IPv4 address inside (I learned about NAT64 and Teredo the hard way while writing that blocklist). Restrict the destination port, so the TLS inspector can't be turned into a port scanner. Check content-length, then stream the body and stop at a cap instead of buffering it. Rate-limit by a client key that isn't derived from x-forwarded-for, since anyone can set that header. Keep uploads in memory and never touch the disk. And store no input and no output, period.

Analytics follows the same idea. An event carries the tool id and nothing else. I can see that someone opened the cron visualizer today. I have no idea what expression they typed, and I like it that way.

Making the rule visible

A rule that only I know about isn't a privacy feature. It's a promise. So the sidebar shows where each tool runs.

Every tool has a small badge next to its name. 🔒 Client means nothing on that page calls the server. ⚡ Bun means every action does. A tool with both paths shows no badge, and the page itself explains which action leaves the browser. The badge isn't something I type by hand, either. It comes from two flags in the tool registry, the same registry that generates the page title and the search index, so it can't drift out of sync with the code.

And the code is public. KitDev Space is open source under the MIT license, and the repository is linked from the site footer. If a badge says Client, you don't have to trust the badge. You can open the tool's module and see for yourself that nothing in it calls a server. That was the last piece of the "don't take my word for it" idea, and honestly the part I should have done first.

What's in there

New tools land most weeks, so I won't give you a count. Here are the ones I open most often, by category.

Data: a JSON formatter that accepts JSON5 and JSONC, JSON to TypeScript, converters between YAML, TOML, XML and CSV (including CSV to SQL inserts), a table viewer for large CSVs, and the SQLite studio.

Dev: a regex tester that explains each token, a cron visualizer that shows the next runs, cURL to fetch/Axios/Python/Go, HTML and SVG to JSX or Vue, a glob tester, and the tar explorer.

Network: TLS inspector, DNS lookup, email health check, HTTP header inspector, CIDR calculator, cookie inspector, RDAP lookup.

Crypto: hash generator, HMAC, JWT debugger, TOTP generator, AES encrypt and decrypt, UUID and passphrase generators.

Color: an OKLCH converter, a WCAG contrast checker, a Tailwind shade generator, a CSS gradient studio, and palette extraction from an image.

Image: crop, resize, rotate and convert in one pass, an EXIF inspector and remover, SVG to PNG or WebP at 1x/2x/4x, and a favicon set generator that hands you a ZIP.

There's no account, no paywall, and the whole thing is open source. The site follows your system color scheme, so you won't have to hunt for a toggle.

Under the hood

Nuxt 4 and Nuxt UI 4 on the front end, VueUse for composables, CodeMirror for the editors, Bun for the server routes, Vitest and Playwright for tests, deployed on Vercel. Nothing exotic.

I'd like your help

If you try kitdev.space, I have two requests. Tell me which tool you wanted and couldn't find. And if you ever catch a tool sending something to the server that should have stayed in your browser, tell me that first. It would mean the rule has a hole, and I'd want to know.

The repository is one click away from the footer. Issues and pull requests are welcome, whether it's a new tool, a fix, or just a note that a badge is wrong. A tool hub like this gets better with more hands on it, which is the main reason I opened the source.

If you build tools of your own, take the rule with you. Write down the handful of cases where the browser truly can't do the work. Everything else belongs on the user's machine.

DEV Community: Hamed