About Us

SafeWebTools started as a folder of half-finished scripts on a security engineer's laptop — a bcrypt verifier here, an HMAC one-liner there, a bookmarklet for decoding Base64 JWT segments during on-call. The recurring frustration was that every "quick" online alternative asked us to paste secrets, private keys, or production data into a stranger's form. For people who spend their day thinking about threat models, that is an unacceptable ask. So we rebuilt the workbench the way it should have been from the start: every primitive runs client-side, in your browser, using the Web Crypto API, so plaintext and keys never leave the tab they were typed into.

Our mission is narrow on purpose. We are not trying to be a general utility grab-bag; we are trying to be the crypto and encoding bench a developer, a security engineer, or a computer-science student actually trusts. That means being honest about the sharp edges — telling you plainly that MD5 and SHA-1 are broken, that client-side crypto is only as safe as the machine running it, and that a strong passphrase matters more than any clever tool. We would rather explain a limitation than paper over it, because the people who use these tools are the same people who read the source before they run it.

The site is edited by an application-security practitioner who writes the accompanying guides on hashing, key exchange, and breach response, and who reviews each tool's behavior against the specs it claims to implement. When a primitive changes — a new digest, a tighter default cost factor, a clearer error on failed GCM authentication — the reasoning goes into the blog rather than a silent commit, so you can decide for yourself whether to trust it.

If you have found a bug, want a primitive added, or think one of our security claims deserves a stronger caveat, we genuinely want to hear it. Write to [email protected] — real messages reach a real engineer, and correction requests get priority over feature ones.