What the Hash Generator Does
The Hash Generator computes a cryptographic hash of any text using the browser's Web Crypto API. Paste your input, pick an algorithm from the selector — SHA-1, SHA-256, SHA-384, or SHA-512 — and the output panel shows the digest as a lowercase hexadecimal string. An info line reports the algorithm used and the input's size in bytes, so you always know what was hashed.
The four choices are exactly what Web Crypto's
subtle.digest supports for general hashing — this tool deliberately does not offer MD5, which Web Crypto omits because MD5 is cryptographically broken. If you specifically need an MD5 digest for a legacy non-security purpose, the
MD5 Generator implements it directly. Likewise the SHA-1 page exists separately because SHA-1, while still in the API, carries its own collision history worth understanding before you rely on it.
Hashing is one-way by construction. The digest is a fixed-length fingerprint — 160 bits for SHA-1, 256 for SHA-256, 384 for SHA-384, 512 for SHA-512, regardless of whether the input is one character or one million. You cannot recover the input from the hash; you can only hash a candidate input and compare. That asymmetry is the entire point, and it is what makes the digest useful for integrity checks, fingerprints, and deduplication — and useless for storing anything you will need to read back.
How the Hash Generator Works
All four algorithms are members of the Merkle–Damgård family: the input is padded to a multiple of the block size, split into blocks, and each block is mixed into a running internal state seeded by a fixed constant. The final state is the digest. The variants differ in two knobs — the digest width and the number of rounds — and those knobs produce the practical differences you see in the output lengths.
SHA-256, the workhorse, processes 512-bit blocks through 64 rounds of arithmetic over eight 32-bit words and emits 256 bits (64 hex characters). SHA-512 scales everything up — 1024-bit blocks, 80 rounds, eight 64-bit words, 128 hex characters — which is also why SHA-512 can be faster than SHA-256 on 64-bit processors: fewer rounds over wider words. SHA-384 is SHA-512 with the output truncated to 384 bits, a convenient width for HMAC use. SHA-1 is the 1995-era predecessor: 160-bit digest, and structurally weakened in ways the SHA-2 family was designed to avoid.
Mechanically the tool is a thin, honest wrapper. Your text is encoded to UTF-8 bytes — worth remembering, because the hash is of the bytes, and a multi-byte character like é contributes two bytes — then passed to crypto.subtle.digest with the selected algorithm, and the resulting 32/48/64-byte buffer is rendered as two-digit hex per byte. Nothing is added to the input: no salt, no key, no secret. The same input always yields the same digest on every machine, which is exactly what makes hashes comparable across systems.
That determinism cuts both ways: it lets you verify a download or deduplicate a file, and it means a hash leaks structure — identical inputs produce identical outputs, and unsalted hashes of passwords fall to precomputed tables. Hashing identifies; it does not conceal. Where a secret must be involved, that is HMAC's job.
Using the Hash Generator
- Step 1 — Paste or type the input. Any text. Whitespace is part of the input: a trailing newline changes the hash completely, which is the most common reason two hashes of "the same" text disagree.
- Step 2 — Choose the algorithm. The selector offers SHA-1, SHA-256, SHA-384, SHA-512, defaulting to SHA-256. For new work SHA-256 is the standard choice; pick SHA-512 for the wider digest, SHA-384 when a spec calls for it, and SHA-1 only when a legacy format demands it.
- Step 3 — Read the digest. The output is lowercase hex — 40 characters for SHA-1, 64 for SHA-256, 96 for SHA-384, 128 for SHA-512. The info line repeats the algorithm and the byte count of what you hashed.
- Step 4 — Compare digests, not inputs. When verifying data against a published hash, compare the strings directly or paste both into the Hash Comparison Tool. Case differences in hex are the usual cosmetic mismatch — the comparison tool ignores them.
- Step 5 — Re-run to confirm determinism. The digest is identical every run — no salt, no randomness. Outputs that must differ (passwords, tokens) belong to keyed or salted constructions, not this tool.
Common Use Cases
Verifying downloads and published artifacts. Software distributions publish SHA-256 digests alongside releases. Hash the file's text content here and compare against the published value to confirm nothing was corrupted or substituted in transit. (For binary files see the caveat on the
File Hash Checker, which computes all three SHA variants in one pass.)
Cache keys and deduplication. Hash a payload and use the digest as the storage key: identical content collapses to identical keys, and changed content cannot collide.
Fingerprinting configuration and API payloads. Before a migration or a refactor, hash the current config or a canonical request body; after, hash again and compare. The two digests differing is an early-warning signal that something semantic changed even when the diff looks innocent.
Understanding digest lengths when integrating. If a spec says "SHA-384, hex-encoded," this tool shows you what that string looks like — 96 characters — before you write code against it.
Teaching what one-way means. Hash a sentence, then try to derive the sentence from the digest. The exercise makes the asymmetry concrete in a way descriptions rarely do.
Worked Example
Hash the canonical test string hello world with SHA-256 (the default):
b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
That is the exact digest every conforming SHA-256 implementation produces for those eleven bytes — Node's crypto, OpenSSL, Python's hashlib, this tool's Web Crypto. The info line reads SHA-256 · 11 bytes input. Switch the selector to SHA-1 and the same input yields 2aae6c35c94fcfb415dbe95f408b9ce91ee846ed — 40 characters, a different fingerprint from a different construction. Both are correct; they are simply different functions.
Now the sensitivity demonstration, which is the fastest way to internalise the avalanche property. Add a single trailing space and re-run: the SHA-256 digest changes in roughly half its bits, to 3d583c65db6e2a0d8c7af0d0bfeab0d0c5f6b4012e5e4b2e1f9e5a0b3b7d4a1f-shaped output bearing no visible relationship to the first. No partial similarity survives; the two digests are unrelated strings. Compare two hashes of "the same" document that differ at all, and the honest conclusion is the documents differ — even a single invisible byte of whitespace.
Tips and Common Mistakes
- Whitespace is input. Trailing newlines from copy-paste, a final period added by an editor, CRLF versus LF line endings — each changes the hash. When two digests of "identical" text disagree, diff the bytes before doubting the algorithm.
- Pick SHA-2 family for new work; treat SHA-1 as legacy. SHA-1 remains available because formats still specify it, but collision attacks against it are practical. Nothing new should depend on its collision resistance.
- A plain hash is not password storage. Unsalted, unkeyed digests of passwords fall to rainbow tables at scale. Salted, deliberately slow hashing — bcrypt — is the tool for credentials, and this domain provides it.
- Hex encoding doubles the length. The digest itself is 32 bytes for SHA-256; the 64-character string is its hex representation. If an API expects raw bytes and you paste hex (or vice versa), mismatches look like wrong hashes but are wrong encodings.
- Do not roll comparisons yourself in production code. This tool compares by eye and by the comparison tool for humans; server-side verification should use a constant-time comparison so response timing cannot leak how many bytes matched.
- The digest proves integrity, not authenticity. Anyone can recompute the hash of a modified file. Proving who produced the data requires a keyed construction — HMAC — or a signature.
Frequently Asked Questions
Why is there no MD5 option?
MD5 is cryptographically broken and Web Crypto deliberately omits it. For legacy non-security digests, the
MD5 Generator implements the algorithm directly.
Which algorithm should I choose?
For new integrations, SHA-256: it is the default assumption of most specs, fast enough for any interactive use, and 64 hex characters. Choose SHA-384 or SHA-512 when a specification names them or when you want the wider margin; SHA-512 can even be faster on 64-bit hardware for large inputs. SHA-1 only for reading legacy formats — never for new signatures or integrity guarantees.Is the output the same on every computer?
Yes — that is the property. SHA-256 of the same bytes is the same 64 hex characters in every conforming implementation: this browser tool, Node, OpenSSL, Python, Java. If two implementations disagree on the same input, the input bytes are not actually the same — encoding and whitespace are the usual culprits.Can I hash a file here?
This page hashes pasted text; the
File Hash Checker handles uploads with all three SHA algorithms in one pass — with its documented text-mode caveat for binary files.
Does hashing reveal what the input was?
Not directly — you cannot invert a digest — but plain hashing does not hide low-entropy inputs. A hash of a password, a small ID, or a name from a short list can be confirmed by hashing candidates until one matches. That is why salted, keyed, or deliberately slow constructions exist for anything an attacker could guess. For arbitrary long text, the digest leaks effectively nothing.Related Tools