Hash Generator

MD5 and SHA-1 are considered cryptographically broken — collisions have been demonstrated. They are still used for non-security checksums (e.g. file integrity) but should never be used for passwords or digital signatures. SHA-256 and SHA-512 (SHA-2 family) and the newer SHA-3 family remain secure for cryptographic purposes.

No — not these general-purpose hashes. Use a purpose-built password hashing algorithm like bcrypt, Argon2, or scrypt which are slow by design and include a salt to resist rainbow table attacks. See the Bcrypt Generator tool.

MD5 (128-bit output) is cryptographically broken — practical collision attacks have been demonstrated since 2004. SHA-1 (160-bit output) is also considered broken — Google demonstrated a practical collision in 2017 (SHAttered attack). SHA-256 and SHA-512 (the SHA-2 family) remain secure. SHA-3 (Keccak) is the latest standard, based on a sponge function construction. For non-security checksums, MD5 and SHA-1 remain usable since preimage resistance is still intact.

Hash functions are designed to be computationally infeasible to reverse — this property is called preimage resistance. A hash function maps an input of arbitrary length to a fixed-size output. Because the output is smaller than many possible inputs, information is inherently lost. Cryptographic hash functions add the guarantee that finding any input that produces a given hash requires brute-force effort proportional to 2ⁿ operations (where n is the output bit length).

A rainbow table is a precomputed lookup table mapping common passwords to their hash values. An attacker who obtains a database of unsalted password hashes can look up each hash and instantly recover the original password. A salt is a random value appended to each password before hashing. Because every password gets a unique salt, rainbow tables become useless. This is why modern password hashing algorithms like bcrypt, Argon2, and scrypt automatically generate and store a random salt with each hash.

A hash collision occurs when two different inputs produce the same hash output. By the pigeonhole principle, collisions must exist in any hash function (infinite inputs, finite output space), but a secure hash function should make finding collisions computationally infeasible. MD5 collisions can be generated in seconds on a modern computer. A collision attack is catastrophic for digital signatures and certificates because an attacker could get a legitimate cert signed for one document and fraudulently apply it to a different one.

File integrity verification works by computing the hash of a file and comparing it to a known-good checksum published by the file's distributor. If even a single bit in the file has changed, the hash will be completely different. Common examples: Linux distributions publish SHA-256 checksums for ISO downloads; package managers like apt and npm verify package hashes before installation. To verify: sha256sum downloaded-file.iso on Linux/macOS.

HMAC (Hash-based Message Authentication Code) combines a hash function with a secret key to produce a message authentication code. Unlike a plain hash (which anyone can compute), an HMAC can only be verified by someone who knows the secret key. HMACs verify both the integrity and authenticity of a message. They are used in JWTs, API authentication (AWS Signature, Stripe webhooks), and cookie signing. Use HMAC-SHA256 — avoid HMAC-MD5 and HMAC-SHA1 for new designs.

Encryption is reversible — if your encryption key is compromised, all stored passwords can be decrypted. Hashing is one-way — even if an attacker obtains the hash database, they cannot reverse the hashes without a brute-force attack. At login time, you hash the user's input and compare it to the stored hash — you never need to recover the original password. Use Argon2id, bcrypt, or scrypt — never SHA-256 or MD5 directly for passwords.