guideΒ·devΒ·4 min read

Why Client-Side Tools Are Safer for Secrets (Hashes, Passwords, JWTs)

UtiLabs Security Deck
July 9, 2026

Interactive Sandbox Ready

Launch the interactive Hash Generator Lab to test these principles.

Launch Tool

1. Two Very Different Trust Models

Most 'online tool' sites for hashing, encoding, or password generation work by sending your input to a server, processing it there, and returning the result. That server now has a copy of whatever you typed β€” even if it claims not to log it. You're trusting a promise, not a mechanism.

Client-side tools built on the browser's SubtleCrypto API (or equivalent pure-JS math for things like Base64/JWT decoding) never transmit your input anywhere. The computation happens in your browser's sandbox and the result never leaves your machine unless you copy it yourself. That's a structural guarantee, not a policy one.

2. How to Tell the Difference

Open your browser's network tab (DevTools) while using a hashing or encoding tool. If you see a POST request firing every time you type, your data is leaving the browser. If the network tab stays quiet, the tool is computing locally. This takes about ten seconds to check and is the single most reliable way to verify a privacy claim instead of just reading one.

Never paste a real production secret, private key, or password into any tool β€” including client-side ones β€” without first checking the network tab yourself. Verify, don't trust the label.

3. Where This Matters Most

It matters most for anything you wouldn't want logged: JWT decoding (tokens often carry user IDs or session data), password/secret generation (the whole point is that nobody else should see the output), and hashing of anything derived from real credentials. It matters less for genuinely public data β€” formatting a public JSON API response, for instance β€” where server round-tripping is a non-issue either way.