Passwords, Hashes and Random Numbers: How the Security Tools Actually Work
Security tools have a strange property: the less magical they seem, the more you can trust them. A password generator that explains where its randomness comes from is worth more than one that just promises "military-grade security." So this post opens the hood on five of the most-used security tools on this site — the password generator, the strength checker, the hash generator, the UUID generator and the JWT decoder — and explains the small amount of genuinely interesting computer science inside each one.
Randomness: the foundation everything sits on
Every security tool begins with the same question: where do the random numbers come from? It matters more than anything else. JavaScript's ordinary Math.random() is a pseudorandom generator designed for speed — fine for shuffling a playlist, dangerous for secrets, because its output can be predicted if an attacker learns its internal state. Browsers therefore provide a second source: crypto.getRandomValues(), which draws from the operating system's cryptographic randomness pool — the same one used to generate encryption keys. Our Password Generator uses only this cryptographic source. That single implementation choice is the difference between a password that is genuinely unguessable and one that merely looks it.
What actually makes a password strong
Password strength is usually explained with rules — "add a symbol, add a number" — but the real measure is entropy: how many equally likely possibilities an attacker must try. Each character drawn uniformly from a set of N symbols contributes log₂(N) bits. Lowercase letters alone give about 4.7 bits per character; adding uppercase, digits and symbols raises the pool to roughly 90 symbols, about 6.5 bits per character. The arithmetic compounds fast: a 16-character password from the full set carries over 100 bits of entropy — a number so large that every computer on Earth working together could not brute-force it before the Sun burns out. Length beats cleverness: four extra random characters help more than any amount of creative substitution, because attackers' tools already know that "P@ssw0rd" is just "password" wearing a hat.
That's also what our Password Strength Checker is really scoring. It examines length, the variety of character classes actually present, and repeated or sequential patterns that shrink the effective search space. One design decision worth stating plainly: the check runs entirely in your browser's memory. A strength checker that sends your candidate password to a server for "analysis" would be indistinguishable from a phishing form — which is precisely why ours doesn't have a server to send it to.
Hashes: one-way math
A hash function takes any input — a word, a file, a novel — and produces a fixed-size fingerprint, such that the same input always yields the same fingerprint, while working backwards from fingerprint to input is computationally infeasible. Change one letter of the input and the output changes beyond recognition. That one-way property powers half of computing: websites store hashes of passwords rather than passwords, download pages publish a file's hash so you can verify your copy arrived intact, and version-control systems identify every change by its hash. Our Hash Generator computes these fingerprints with the browser's built-in WebCrypto engine — the same audited implementation the browser uses for HTTPS — rather than a JavaScript re-implementation.
UUIDs: unique without asking anyone
Distributed systems constantly need identifiers that won't collide — order numbers, device IDs, database keys — generated by machines that can't coordinate with each other. The version-4 UUID solves this with brute statistics: fill the identifier with 122 cryptographically random bits. The number of possible v4 UUIDs is about 5.3 × 10³⁶; generate a billion per second for a century and the odds of ever producing a duplicate remain negligible. No registry, no central authority — just a random number so large that uniqueness follows from arithmetic. Our UUID Generator produces them from the same cryptographic source as the password tool, formatted to the RFC 4122 layout with the version and variant bits set correctly.
JWTs: decoding is not verifying
JSON Web Tokens travel through every modern login flow, and they confuse people because they look encrypted while mostly being merely encoded. A JWT is three Base64-encoded segments: a header, a payload of claims (user ID, expiry, roles), and a signature. Anyone can decode the first two — that's what our JWT Decoder does, locally, for debugging. What no decoder can do is verify the token, because verification means recomputing the signature with the issuer's secret key, which you (and we) don't have. The tool says this on its own page, and it's the one sentence about JWTs worth memorizing: a decoded token tells you what it claims; only a verified signature tells you whether to believe it. Systems that skip that distinction end up in security post-mortems.
Why "in your browser" is a security feature here
Every tool in this post handles material you should never share: candidate passwords, tokens from live systems, values you're about to hash into something sensitive. Running the computation client-side isn't just a privacy preference — it removes an entire category of risk. There is no server log to leak your inputs, no transit to intercept, no database of "recently generated passwords" to breach, because none of those things exist. The browser downloads a page of static JavaScript, and everything after that happens on your machine. You can even load the tool, disconnect from the internet, and it keeps working — which is a test you're welcome to run.
Practical defaults to walk away with
- Passwords: 16+ characters, full character set, generated randomly — then stored in a password manager, because the only unguessable password is one you didn't have to remember.
- Hashes: SHA-256 for anything new; MD5/SHA-1 only to check values that were published in those formats.
- Identifiers: v4 UUIDs whenever independent systems must not collide.
- Tokens: decode to debug, verify to trust — and never paste production tokens into any website that transmits them.
None of this is exotic. It's a handful of clean ideas — real randomness, entropy, one-way functions, statistical uniqueness, signatures — implemented carefully and explained in the open. That's what security tooling should look like: not magic, just math you can check.
