/
Security

7 Free Online Security Tools

Security tools are the last thing you should paste a secret into on a random website, which is the reason these 7 are built the way they are: hashing, signing, and key generation all happen inside your browser through the Web Crypto API, so keys and payloads never travel anywhere. Hash Generator computes MD5, SHA-1, SHA-256, and SHA-512 digests. HMAC Generator signs a message with a shared secret, the mechanism behind most webhook verification. RSA Key Generator creates a 2048 to 4096-bit key pair as PEM. JWT Builder issues and signs a token, and SSL Certificate Decoder unpacks a PEM certificate so you can read its subject, issuer, and expiry. Password Strength Checker and CORS Request Tester round out the set.

All 7 Security tools

What you can do with these security tools

Each one maps to a task that normally means remembering an openssl incantation.

  • Hash — MD5, SHA-1, SHA-256, and SHA-512 digests of any text, for checksums and fingerprints.
  • Sign and verify — HMAC-SHA256 and friends from a message and secret, as hex or Base64, matching what webhook providers expect.
  • Generate keys — RSA key pairs at 2048, 3072, or 4096 bits, exported as PEM, generated on your device.
  • Issue tokens — build and sign a JWT with a custom payload using HS256, HS384, or HS512.
  • Inspect certificates — decode a PEM X.509 certificate to see subject, issuer, validity dates, serial, and SANs.
  • Assess and test — measure password entropy and estimated crack time, and check whether an endpoint CORS policy allows your origin.

What a hash is and is not for

A hash is one-way: it fingerprints data so you can detect a change, and it cannot be reversed to recover the input. That makes SHA-256 right for verifying a download or comparing two files, and wrong for storing passwords — a fast hash is exactly what an attacker wants, which is why password storage needs a deliberately slow algorithm such as bcrypt, scrypt, or Argon2 with a per-user salt. MD5 and SHA-1 deserve a similar caveat: both are broken for collision resistance and should be treated as checksums for accidental corruption, never as a security control. If your goal is to prove a message came from a particular sender rather than merely that it is unchanged, you want an HMAC or a signature, not a bare hash.

Related categories

Frequently asked questions

6

These tools use the browser Web Crypto API and do all their work locally, so the key, message, or certificate is never transmitted. As a general habit, still prefer rotating anything you have pasted into any web page you did not build yourself.

No. MD5 and SHA hashes are fast by design, which makes them cheap to brute-force. Password storage needs a slow, salted algorithm such as bcrypt, scrypt, or Argon2 — use hashing here for checksums and fingerprints instead.

Not for anything security-critical. Both have practical collision attacks, so treat them as integrity checks against accidental corruption or as legacy compatibility, and use SHA-256 or better where the result matters.

Yes. The key pair is generated in your browser by the Web Crypto API and never sent anywhere, so the private key exists only on your device until you copy it. For a production key, generating it on the target machine is still the stronger habit.

A hash proves data has not changed. An HMAC mixes a shared secret into the hash, so it also proves the sender knew that secret — which is why webhook providers sign payloads with an HMAC rather than a plain digest.

Usually an algorithm or secret mismatch: a token signed with HS256 and one secret will not verify against a different secret or an RS256 public key. Decode the token first to check the alg header and the claims before hunting further.