Generate MD5, SHA-1, SHA-256 and SHA-512 hashes from any text. 100% browser-local — your data never leaves your device.
🔒 Privacy: hashing runs entirely in your browser. Nothing is uploaded anywhere.
Part of the Developer Tools collection — browse all related free tools.
A cryptographic hash function turns any input into a fixed-length fingerprint. The same text always gives the same hash, but you cannot reverse a hash back to the original text. Developers use hashes to verify downloads, store passwords safely and detect data changes.
A hash generator converts any text into a fixed-length string of characters (a hash) using algorithms like MD5 or SHA-256. The same input always produces the same hash.
Hashes verify file integrity, store passwords securely, create checksums for downloads, and generate unique IDs for data.
Yes. All hashing happens locally in your browser via JavaScript — nothing is sent to any server.
Yes. It is 100% free with no signup required.
Theoretically yes, but with 2^256 possible outputs it's computationally infeasible — no SHA-256 collision has ever been found. For all practical purposes, matching hashes mean identical files, which is why checksums are trusted worldwide.
So you can verify the file wasn't corrupted or tampered with during download. Hash your copy and compare it with the published value — an exact match proves integrity; any mismatch means you should download again from the official source.
Not directly — SHA-256 is designed to be fast, which makes brute-force attacks easy. Password storage needs deliberately slow, salted algorithms like bcrypt, Argon2, or PBKDF2 that make each guess expensive for attackers.
A hash function takes any input of any size and produces a fixed-length fingerprint. Good hash functions have four properties: deterministic (same input → same output, always), one-way (you can't reconstruct the input from the output), avalanche effect (changing one bit scrambles the whole output), and collision resistance (it's infeasible to find two inputs with the same output). Everything here is computed locally in your browser.
The common algorithms: MD5 (128-bit, 32 hex chars) — fast but cryptographically broken; SHA-1 (160-bit, 40 hex) — deprecated after real collisions were demonstrated; SHA-256 (256-bit, 64 hex) — the current standard for integrity checks. Longer digests and stronger internal mixing are what separate the secure from the broken.
Worked example: SHA-256 of "hello" = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. Change one letter — "hellp" — and the digest becomes completely different; that's the avalanche effect. This is exactly how download verification works: hash your file, compare with the publisher's checksum, and an exact match proves the file is intact.
Practical tips: use SHA-256 for file verification, checksums, and data-integrity checks; never use MD5 or SHA-1 for anything security-related. Limitation: hashing is not encryption — it doesn't hide data, it fingerprints it. And never hash passwords with plain SHA-256; password storage needs slow, salted algorithms like bcrypt or Argon2.
Hashes in real systems: Git identifies every commit by its SHA-1 hash (migrating to SHA-256) — the hash is the commit's identity, which is why history can't be silently altered. HMAC (hash-based message authentication) combines a secret key with hashing so APIs can verify both integrity and authenticity — webhooks from Stripe and GitHub are signed this way. Blockchain chains blocks by including the previous block's hash, making tampering cascade-detectable. Digital signatures hash the document first, then encrypt the hash with a private key — signing the short hash instead of the whole file is what makes it fast. One critical distinction: checksums vs password hashing — file integrity wants fast hashes (SHA-256), but password storage wants deliberately slow ones (bcrypt, Argon2, ~100ms per guess) so brute force becomes impractical. Using a fast hash for passwords is a classic vulnerability; using a slow hash for file checksums is just wasteful.