Hash Generator
Generate MD5, SHA-1, SHA-256, SHA-384 and SHA-512 digests from any text. Everything runs locally in your browser, so your input is never uploaded.
Input Text
0 chars
Hashes
Enter text above to see its hashes.
How to use Hash Generator
- 1
Enter your text
Type or paste any text into the input panel; hashes are calculated automatically from its UTF-8 bytes.
- 2
Read every digest
View the MD5, SHA-1, SHA-256, SHA-384, and SHA-512 results together, each updating live as you type.
- 3
Choose the right algorithm
Pick SHA-256 or stronger for anything security-related, and reserve MD5 or SHA-1 for non-security checksums and legacy compatibility.
- 4
Copy a hash
Click Copy on any row to put that hexadecimal digest on your clipboard, all without leaving your browser.
Hash Functions Explained: Digests, Integrity, and What Not to Do
What a hash function does
A cryptographic hash function takes input of any length and produces a fixed-length string of bytes called a digest, usually shown as hexadecimal. SHA-256 always emits 256 bits — 64 hex characters — whether you feed it a single letter or a gigabyte file. The function is one-way by design: computing the digest from the input is fast, but recovering the input from the digest is computationally infeasible. That asymmetry is the whole point.
This generator computes five digests from the same text at once — MD5, SHA-1, SHA-256, SHA-384, and SHA-512 — using the Web Crypto API where available. Seeing them side by side makes the trade-offs concrete: the older functions are shorter and faster, the SHA-2 family is longer and built for security work.
Determinism and the avalanche effect
Hashes are perfectly deterministic. The same input always yields the same digest, every time, on every machine and in every correct implementation — which is exactly what makes them useful for comparison and verification. Type the word hello and you get one specific SHA-256 string; type it again tomorrow and you get the identical string.
Yet the mapping is wildly sensitive to input. Change a single character — even flip the case of one letter or add a trailing space — and a good hash function produces a completely different, unrecognizable digest, with roughly half the output bits flipping. This is the avalanche effect, and it is why digests are useless for guessing how similar two inputs were: nearly identical inputs look totally unrelated, which is a feature, not a bug.
The everyday use: integrity and checksums
The most common legitimate use of a hash is verifying that data arrived intact. A download page publishes the SHA-256 of a file; after downloading, you hash your copy and compare. If the two digests match character for character, the file is byte-identical to the original and was not truncated or corrupted in transit. If even one bit differs, the digests will not match.
The same property powers deduplication and change detection. Storage systems hash blocks to spot duplicates without comparing them byte by byte, version-control systems and caches use content hashes as identifiers, and build tools hash inputs to decide whether work can be skipped. In all of these, the hash is a compact, reliable fingerprint of content.
Hashing is not encryption
This confusion is everywhere and it matters. Encryption is reversible: with the right key you can recover the original plaintext, because the whole purpose is to protect data you intend to read again later. Hashing is one-way on purpose — there is no key and no decrypt step, because the goal is a fingerprint, not a recoverable copy.
So a hash is never the answer to make this text secret but readable later. If you need to store something and get it back, you want encryption. If you only ever need to check whether a later input matches an earlier one without storing the original, you want a hash. Reaching for the wrong one is a design error that no amount of algorithm strength can fix.
MD5 and SHA-1 are broken for security
MD5 and SHA-1 are still computed here because they remain useful for non-security checksums, legacy interoperability, and matching values produced by old systems. But both are cryptographically broken: researchers have produced practical collisions, meaning two different inputs that hash to the same digest, and for SHA-1 this has been demonstrated with real, meaningful files. A collision destroys the security guarantee that a digest uniquely identifies its input.
The practical rule is simple. Never use MD5 or SHA-1 where an attacker could benefit from forging a match — digital signatures, certificate fingerprints, tamper-evident logs, or anti-collision identifiers. For anything security-sensitive, choose SHA-256 or stronger. Keep the legacy functions for casual integrity checks where no adversary is in the picture.
Why plain hashing is wrong for passwords
It is tempting to store a password by saving its SHA-256 and comparing on login, but this is a serious mistake. General-purpose hashes are built to be fast, and that speed lets attackers try billions of candidate passwords per second against a stolen database. Worse, two users with the same password produce the same digest, and precomputed lookup tables (rainbow tables) can reverse common passwords instantly.
Proper password storage uses a slow, salted, purpose-built key-derivation function — bcrypt, scrypt, or Argon2 — where a unique random salt per user defeats lookup tables and a deliberate cost factor makes brute force expensive. A salt is simply random data combined with the password before hashing so that identical passwords yield different stored values. Use this tool to understand and verify hashes, but do not use a bare SHA digest to store credentials.
Encoding, output format, and privacy
Because a hash operates on bytes, the text encoding must be fixed or the digest is meaningless across tools. This generator encodes your input as UTF-8 before hashing, so accented letters, non-Latin scripts, and emoji all produce standard digests that match other UTF-8 based implementations. If a digest you compute elsewhere disagrees, an encoding mismatch — or a stray trailing newline — is the usual cause.
Everything runs locally in your browser; your input is never uploaded, logged, or stored, which makes it safe to hash tokens, file contents, or other sensitive values. A handy verification habit is to paste a known input and confirm the digest matches the value your application or a download page reports — when they agree byte for byte, both sides are encoding and hashing the same thing.
Frequently asked questions
Which hash algorithms does this tool generate?
Is my input sent to a server?
Should I use MD5 or SHA-256?
Can a hash be reversed back to the original text?
Does it handle Unicode and emoji correctly?
Related tools
Keep going with these handy tools