Developer Utilities

This is the single most consequential distinction in this category, and conflating the terms causes real security incidents. Encoding - Base64, percent-encoding - is a reversible change of alphabet with no key and no secret. Anyone can undo it instantly. Its purpose is transport: letting binary or reserved characters survive a channel that only handles plain text.

Hashing - SHA-256, and the legacy MD5 and SHA-1 - is deliberately one-way. It maps input of any size to a fixed-size digest that cannot be reversed. Its purpose is integrity and identity, not confidentiality: verifying a download, deduplicating files, or comparing values without storing them.

Encryption is the only one of the three that provides confidentiality, and none of the tools here perform it. If you need something to be unreadable by whoever holds it, Base64 will not do it and neither will a hash. cGFzc3dvcmQ= is not a protected password; it is the word password in a different alphabet.

The same trap appears with JSON Web Tokens. A JWT is three Base64url segments joined by dots, and reading the header and payload requires no key whatsoever - which is why the decoder can show you the claims entirely in your browser. That is decoding.

Verifying is checking the third segment, the signature, against the issuer's secret or public key, and confirming that exp, nbf, iss and aud are acceptable. Only that step tells you the token is genuine. Reading a token's claims and acting on them without verifying the signature means trusting a string that anyone could have written, and it is a recurring source of authentication bypasses.

The generators here draw from crypto.getRandomValues(), the browser's cryptographically secure random source, rather than Math.random(). That distinction matters for passwords and tokens, where a predictable generator is equivalent to no generator, and it is why these values are produced locally in your tab and never transmitted or stored.

Choosing between identifier formats is mostly a question of what you need from them. UUIDv4 is 122 random bits with universal library support but no ordering, which fragments database indexes when used as a primary key. UUIDv7 keeps the same format while prefixing a millisecond timestamp, so values sort chronologically and index well. Nano IDs are shorter and URL-safe by default, which suits public-facing identifiers where a 36-character UUID is unwieldy.