Hash Generator
Generate SHA-256, SHA-1 and CRC32 hashes of any text in your browser, with guidance on which one is appropriate for what.
How to use this calculator
- 1Paste the text you want to hash.
- 2Pick the algorithm — SHA-256 unless you have a specific reason otherwise.
- 3All three hashes are shown, so you can compare against a checksum in any format.
How the calculation works
digest = H(UTF-8 bytes of input)- H
- The hash function — SHA-256, SHA-1 or CRC32
- digest
- A fixed-length fingerprint, shown in hexadecimal
A cryptographic hash is deterministic (the same input always gives the same output), fast to compute, infeasible to reverse, and highly sensitive — changing one bit of input changes about half the output bits.
The output length is fixed regardless of input size: SHA-256 always produces 256 bits, whether you hash one character or a gigabyte.
These implementations are pure JavaScript and produce identical results to the standard reference vectors.
Worked example
The standard test vector
- 1.This pangram is the conventional test input for hash implementations.
- 2.SHA-256 gives d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592.
- 3.Changing a single letter produces a completely different digest — this is the avalanche property.
Result: d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592
What a hash function does
A hash function takes an input of any size — a single character or an entire file — and deterministically produces a fixed-length string called a digest. The same input always produces the same digest, a tiny change to the input produces a completely different one, and there is no efficient way to work backward from the digest to recover the original input. That combination makes a hash useful as a compact, verifiable stand-in for data you don’t want to store, transmit or compare directly.
It solves a specific problem: how do you tell whether two pieces of data are identical, or whether one has changed, without keeping a full copy of either to compare against? Comparing two 256-bit digests is trivial; comparing two multi-gigabyte files byte by byte is not.
Why some hashes are “broken” and others aren’t
A cryptographic hash function is only as good as its resistance to collisions — two different inputs producing the same digest. MD5 and SHA-1 were both designed as cryptographic hashes, but practical collision attacks have since been demonstrated against both: MD5 in the mid-2000s and SHA-1 publicly in 2017. That means an attacker can now deliberately construct two different inputs that hash the same, which breaks any use case that relies on a hash being unforgeable — digital signatures, certificate fingerprints, integrity checks against a malicious actor.
That does not make MD5 or SHA-1 useless everywhere. Git still uses SHA-1 for object identifiers, and CRC32 was never a cryptographic hash to begin with — it is a checksum designed to catch accidental corruption, not deliberate tampering, and is trivial to forge on purpose. The distinction that matters is whether an adversary is trying to fool the check. Against random noise and accidents, all of these remain fine. Against someone actively trying to defeat them, only an unbroken function like SHA-256 currently holds up.
What hashes get used for
The same one-way, fixed-length property turns up across very different problems:
- File integrity checks — download pages publish a SHA-256 checksum alongside a file so you can confirm what you downloaded matches what was published, byte for byte.
- Version control — Git identifies every commit, file and tree by the SHA-1 hash of its contents, so two identical files anywhere in a repository’s history are automatically recognised as the same object.
- Password storage (with the right algorithm) — a service should never store your actual password — it stores a hash of it, so a stolen database doesn’t hand over usable credentials directly. Ordinary fast hashes like SHA-256 are the wrong tool for this though; it takes a deliberately slow, salted algorithm.
- Deduplication and caching — systems that need to know whether they have already seen a piece of data — a build cache, a content-addressed storage system — use a hash of the content as its lookup key instead of comparing the content itself.
Common misconceptions
A few misunderstandings come up often enough to be worth naming directly:
- “Decrypting” a hash — a hash cannot be reversed by computation. Tools that claim to crack a hash are really looking it up in a precomputed table of common inputs — which only works because so many real passwords are short, common or reused.
- Using a fast hash for passwords — SHA-256 was built to be fast, which is exactly the wrong property for password storage — modern hardware can compute billions of them a second, making a stolen database of fast-hashed passwords crackable at scale.
- Assuming a longer digest is automatically safer — SHA-256’s 256-bit output resists collisions far better than SHA-1’s 160-bit one, but digest length alone doesn’t guarantee security — the algorithm’s design matters as much as its size, which is exactly why SHA-1 is broken despite being longer than some non-cryptographic checksums still used outside security contexts.
What this assumes, and where it stops
Assumptions
- Input is hashed as UTF-8 bytes, which is what almost every system does by default.
Limitations
- Text only. Hashing a file requires reading its bytes, which this text-based tool cannot do.
- MD5 is deliberately not offered — it is comprehensively broken and there is no remaining case where it is the right choice over the alternatives here.
- No HMAC support. Keyed hashing for message authentication is a different operation and needs a proper key.
Common questions
Can a hash be reversed?
Not by computation — hash functions are one-way. Sites claiming to "decrypt" hashes are querying rainbow tables of pre-computed hashes for common inputs. That works for "password123" and fails completely for anything long and random, which is exactly why salting matters.
Is SHA-256 safe for storing passwords?
No. It is far too fast: modern hardware computes billions of SHA-256 hashes per second, so brute-forcing a stolen database is cheap. Password storage needs a deliberately slow, memory-hard function with a per-user salt — Argon2id, scrypt or bcrypt.
Why is SHA-1 still used if it is broken?
Inertia, and because many of its uses are not security-critical. Git uses it for object identifiers where accidental collisions are the concern, not deliberate ones. But for signatures, certificates or anything an adversary could attack, it has been unacceptable since practical collisions were demonstrated in 2017.
Sources
- FIPS 180-4 — Secure Hash Standard — US NIST
- Password storage cheat sheet — OWASP
Formula and content last reviewed on .
Results are estimates for information only, not professional advice.
Related calculators
Tools people commonly use alongside the hash generator.