Free online developer tools
Free online security and crypto tools that run in your browser. Generate hashes, HMAC signatures, AES encryption, JWTs, UUIDs, and strong passwords. No sign-up and values are generated locally on your device.
Generate MD5 and SHA256 hashes.
Create SHA256 hashes instantly.
Create HMAC signatures.
Encrypt and decrypt text.
Decode JWT tokens.
Create JWT tokens.
Create secure passwords.
Generate UUID values.
Generate multiple UUIDs.
These three get used interchangeably in conversation and they are not interchangeable at all. Picking the wrong one is behind a large share of security bugs.
So Base64-encoding a password does not protect it, and storing a SHA-256 hash is not encrypting anything. Match the tool to the goal: transport, integrity, or confidentiality.
The problem with fast hashes for passwords is precisely that they are fast. If a database of
SHA-256 password hashes leaks, an attacker can try billions of guesses per second on commodity
GPUs. Password storage needs a slow, salted, memory-hard function built for the
job: bcrypt, scrypt, or Argon2 (OWASP currently
recommends Argon2id first). These take a tunable cost parameter so you can keep them expensive
as hardware improves.
A natural-looking way to sign a message is hash(secret + message). Do not do this
with MD5, SHA-1, or SHA-256. Those are Merkle–Damgård hashes and are vulnerable to a
length-extension attack: someone who knows the digest of secret‖message
and the length can compute a valid digest for secret‖message‖padding‖extra without
ever knowing the secret. HMAC is constructed specifically to defeat this, which is
why it is the standard primitive for message authentication.
Comparing a token, signature, or hash with == leaks information through timing.
Ordinary string comparison returns as soon as it hits the first differing byte, so an attacker
can measure response time to learn how many leading bytes are correct and forge a value
byte-by-byte. Use a constant-time comparison such as crypto.timingSafeEqual (Node)
or hmac.compare_digest (Python).
Prefer authenticated encryption: AES-GCM detects tampering, while AES-CBC on its own provides no integrity and has a history of padding-oracle attacks. GCM comes with one unforgiving rule — never reuse a nonce (IV) with the same key. A repeated GCM nonce does not merely leak a little plaintext; it lets an attacker recover the authentication key and forge messages. Generate a fresh random nonce for every encryption.
A JWT's header and payload are just base64url — not encrypted — so anyone can read them, and a
decoder that shows you the claims has proven nothing about authenticity. Verification means
checking the signature with the correct key. Two well-known attack classes target the gap: the
alg: none trick, where a token declares it has no signature and a lax library
accepts it, and algorithm confusion, where a token is signed with HS256 using
the server's RSA public key as the HMAC secret while the server expected RS256. Always
pin the expected algorithm on the verifying side.
Encoding (Base64, hex) is reversible with no key and no secrecy — it is for transport. Hashing (SHA-256) is one-way and used for integrity; you cannot recover the input from it. Encryption (AES) is reversible only with a key and is the only one that keeps a value confidential.
No. Fast hashes like SHA-256 and MD5 let an attacker who steals the hashes try billions of guesses per second. Use a slow, salted, memory-hard password hash — bcrypt, scrypt, or Argon2id — with an appropriate cost factor.
No. The header and payload are only base64url-encoded, so anyone can decode and read them. Verification is a separate step that checks the signature against the secret or public key, and it must pin the expected algorithm to avoid alg: none and algorithm-confusion attacks.
Standard comparison stops at the first byte that differs, so its timing reveals how many leading bytes matched. An attacker can use that to reconstruct a valid secret byte-by-byte. Compare secrets with a constant-time function such as crypto.timingSafeEqual or hmac.compare_digest.
No, and it is catastrophic. Reusing a GCM nonce under the same key can expose the authentication key and let an attacker forge messages, not just leak data. Use a unique, randomly generated nonce for every message, and prefer AES-GCM over unauthenticated CBC.