Cryptography that never leaves your browser
Hashing, verification, encryption and key handling done on your own machine, using the cryptographic implementation already built into your browser. Nothing here invents a cipher, and nothing here uploads what you give it.
Processed locally in your browser Files, passwords, keys and text stay on your device. There is no upload step, no server that could receive them, and no analytics event on any of these pages is permitted to carry a value you typed.
Verify and authenticate
Check that a file is the file it is supposed to be.
Generate
Values that need to be unguessable, drawn properly.
Encrypt
Make something unreadable to everyone without the password.
Authenticate and sign
Establish that something came from who you think, and has not changed.
Certificates
Read what a certificate says. Deciding whether to believe it is a different job.
Developer tools
The formats that turn up in an authentication flow.
Convert and inspect
Move data between representations, and understand what you are looking at.
Learn how it works
Educational tools. Nothing in this group protects anything, and each says so.
The rule these tools are built on
Nothing here implements a cryptographic primitive. Every hash, cipher, key derivation and random number comes from Web Crypto — the implementation already in your browser, written and reviewed by the people who wrote your browser. The shared module behind these pages is a documented adapter over it and nothing more.
That boundary is not fussiness. Cryptographic mistakes are unusual in that they produce output which looks entirely correct: the ciphertext is random-looking, the digest is the right length, the round trip works, and the thing is broken anyway. Ordinary testing does not find them. The only reliable defence available to a project this size is to not write the primitive.
Three things the shared module does implement, none of them cryptographic: the RFC 4648 encodings, the byte layout of the encrypted container, and unbiased selection from random bytes. All three are checked against published test vectors or measured distributions.
Tested against published answers, not against itself
A round trip proves only that the code agrees with nobody but itself, which for cryptography is precisely the failure mode. So where a standards body publishes known answers, those are what the engine is checked against: FIPS 180-4 for the SHA family, RFC 4231 for HMAC, RFC 6070 for PBKDF2, the GCM specification's own cases for AES-GCM, and RFC 4648's vectors for Base64 and Base32.
Where no official vectors exist — PBKDF2 with SHA-256, for instance — the engine is checked against an independent implementation instead.
Language you will not find here
Not "military grade", not "unhackable", not "100% secure". None of those describes anything a person could verify. What is written instead is which standard is in use, which implementation performs it, what has been tested, and where the limits are — including the ones that are inconvenient to mention.
The password generator says that requiring one of every character type makes a password weaker. The checksum verifier says that a matching digest published beside the download proves very little. The file hash tool says why very large files fail rather than pretending they do not. That is the tone throughout, and where a tool cannot do something safely it says so instead of doing it badly.
What is not here yet
This category is being built out in phases. Encryption of files and text, digital signatures, HMAC, key generation and inspection, certificate and JWT tools, TOTP, secret sharing and a set of teaching tools for classical ciphers are all specified and coming.
Three of them are waiting on a decision rather than on work: password strength estimation, OpenPGP, and Shamir secret sharing all need a substantial reviewed library, and this site has no build step and does not load code from a CDN. Writing any of those from scratch would break the one rule the whole category rests on.