How it works
The claim this site makes is narrow, specific and testable: what you type into a tool is processed by your own browser and is not transmitted. Here is what that means in practice, and where the limits are.
- Randomness
- crypto.getRandomValues
- Hashing & signing
- SubtleCrypto
- MD5 & SHA-3
- Bundled implementation
- Network calls
- None carry tool input
The browser's CSPRNG, seeded by the operating system. Math.random is never used for key material anywhere on this site.
SHA-1/256/384/512, HMAC, PBKDF2, AES-GCM, RSA and ECDSA come from the browser's native implementation.
Web Crypto does not provide these. They are implemented in the page's JavaScript and verified against the reference test vectors.
No tool posts your input anywhere. The requests a page does make are its own assets, Next.js route prefetches, and a page-view analytics ping — never the contents of a tool.
Verify it rather than trust it
A privacy policy is a promise. This is checkable in about fifteen seconds, and you should check it rather than take the claim on faith:
- Open any tool — the key generator, for example — and let the page finish loading.
- Disconnect from the network, or switch your browser's devtools to offline mode.
- Keep using the tool. It continues to work, because there is nothing on the other end of a wire to call.
- Reconnect, open the network tab, and type into any input. No request is made as you type.
What the guarantee does not cover
Being precise about the boundary is more useful than an absolute claim:
- Your device. A compromised machine, a malicious browser extension, or a keylogger sees everything you type on any page, including this one.
- The delivery of this page. You are trusting that the JavaScript served to you is the JavaScript described here. That is true of every web application. Reading the network tab, or running the site from source, removes the need to trust it.
- What you do next. A key generated safely and then pasted into a chat message is no longer safe. The tool controls its own boundary, not yours.
- Clipboard access. Copying a secret puts it on your system clipboard, where other applications may read it.
Why format-based detection has limits
The scanners match 95 credential signatures across 67 providers. A signature can only recognise a credential that has a recognisable shape. AWS secret access keys, most Azure keys, and any raw hex or Base64 string look like ordinary data, so a clean scan is evidence, not proof. Detection is also purely local: nothing is checked against a provider, so these tools cannot tell you whether a key is currently valid.
Where a browser cannot help
Two things people reasonably ask for are absent, and it is worth saying why rather than approximating them:
- bcrypt and Argon2. Neither is available in Web Crypto. Providing them would mean shipping a large WASM payload for an operation that belongs on your server anyway. The key derivation tool implements PBKDF2 natively and states plainly where Argon2id is the better choice.
- True burn-after-reading links. Deleting a secret after one read requires a server that stores it and then deletes it — which means trusting that server. The encrypted secret link generator solves the adjacent problem honestly instead: it splits a secret into a ciphertext and a key so the two can travel by different routes.
Architecture
Every one of the 64pages is prerendered to static HTML at build time. There is no database, no analytics on tool input, no account system and no API. The interactive parts are React components that call the browser's crypto primitives directly. Content is authored as Markdown in the repository and compiled into the page at build time.