Text & dev
Hash Generator
Type or paste text and instantly compute its cryptographic hashes: SHA-1, SHA-256, SHA-384 and SHA-512, all shown as lowercase hexadecimal. A hash is a fixed-length fingerprint of your input — change even one character and the entire result changes — which makes hashes ideal for verifying file integrity, comparing values without revealing them, generating cache keys and checking download checksums. This tool uses your browser's native crypto.subtle.digest from the Web Crypto API, so the numbers it produces match what any standards-compliant library or command-line tool would give. SHA-256 is the recommended general-purpose choice today; SHA-1 is included for compatibility but is no longer considered secure against deliberate collisions. Everything is computed locally — your text never leaves the page.
Your text
—
—
—
—
Computed with the native Web Crypto API (crypto.subtle.digest) over the UTF-8 bytes of your text. Empty input shows the hash of an empty string.
How the hash generator works
When you type, the tool encodes your text into UTF-8 bytes with TextEncoder and passes those bytes to crypto.subtle.digest for each algorithm. The API returns a raw byte buffer, which the tool converts to a lowercase hexadecimal string — two hex characters per byte. Because hashing is deterministic, the same input always produces the same output, and any change to the input produces a completely different hash.
Output sizes
SHA-1 → 160 bits → 40 hex characters SHA-256 → 256 bits → 64 hex characters SHA-384 → 384 bits → 96 hex characters SHA-512 → 512 bits → 128 hex charactersExample: SHA-256 of "abc" is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad.
Notes & assumptions
- MD5 is intentionally omitted — it is not offered by the Web Crypto API and is broken for security.
- SHA-1 is shown for legacy compatibility only; do not rely on it for security.
- Hashing is one-way: you cannot recover the original text from a hash.
Worked example: checking two configs match without sharing them
You and a teammate suspect your staging .env files have drifted apart, but neither of you wants to paste secrets into a chat. Each of you opens this page, pastes the full file contents into the text box, and reads out the first and last eight characters of the SHA-256 line. If both fragments match, the files are identical byte for byte; SHA-256 makes it computationally infeasible to find two different texts with the same digest, so a matching hash is as good as a full comparison. If they differ, at least one character differs somewhere, and you can narrow it down by hashing each half of the file until you find the drifted line.
One caveat when comparing against command-line output: shell tools hash a file's exact bytes, including any trailing newline, and echo adds one unless you pass -n. If the hash of what looks like the same text refuses to match, a trailing newline or a Windows CRLF line ending is the usual culprit.
Hash algorithms compared: MD5, SHA-1, SHA-256 and SHA-512
Not every hash still in circulation is still trustworthy. The table summarizes the four algorithms people ask about most; "broken" here means researchers can manufacture two different inputs with the same hash (a collision), which destroys the algorithm's value for signatures and certificates.
| Algorithm | Output | Hex length | Collision status | Reasonable uses today |
|---|---|---|---|---|
| MD5 | 128 bits | 32 chars | Broken since 2004; collisions cost seconds on a laptop | Non-security checksums, cache keys, dedupe |
| SHA-1 | 160 bits | 40 chars | Broken in 2017 (Google's SHAttered collision) | Legacy compatibility, git object IDs |
| SHA-256 | 256 bits | 64 chars | No practical attack known | Signatures, certificates, checksums; the default |
| SHA-512 | 512 bits | 128 chars | No practical attack known | Longer digests; often faster on 64-bit CPUs |
SHA-384, also computed above, is SHA-512 with different initial values truncated to 384 bits; it appears mostly in TLS cipher suites and government profiles that require it.
What a hash is not
A hash is not encryption. Encryption uses a key and is designed to be reversed by whoever holds that key; a hash has no key and no decryption operation exists. When a product claims your data is protected because it stores a hash, that is a different guarantee, not a synonym.
A hash is not recoverable, but it is guessable. Since the same input always yields the same output, an attacker who obtains a hash can test candidate inputs at enormous speed, and precomputed tables of common passwords make this instant for weak inputs. That is why a single pass of a fast hash like SHA-256 is not password storage. Real systems use a slow, salted key-derivation function (bcrypt, scrypt or Argon2) tuned so each guess costs real time, turning billions of guesses per second into thousands.
A hash is also not proof of who sent something. Anyone can recompute a plain hash over tampered data; when you need to know data came from someone holding a secret, use an HMAC built on that secret rather than a bare digest.
When MD5 and SHA-1 are still fine
Broken for security does not mean useless. The known attacks let an adversary craft two inputs with the same hash; they do not help anyone reverse a hash or find an input matching a random existing hash. So for jobs with no adversary, the old algorithms remain reasonable: detecting accidental corruption in file transfers, building cache keys and ETags, bucketing records across shards, and deduplicating content where an engineered collision would gain an attacker nothing.
Git is the famous large-scale SHA-1 holdout: it identifies every object by a SHA-1 hash, has shipped a hardened variant that detects the known collision technique since 2017, and offers a SHA-256 object format for new repositories. The rule of thumb: if a deliberately crafted collision would let someone profit (forged signatures, spoofed certificates, poisoned downloads), use SHA-256 or better. If the only failure mode is accidental corruption, MD5's speed is still a legitimate advantage.
Frequently asked questions
Which hash should I use — SHA-256 or SHA-512?
For almost everything, SHA-256 is the right default: it is fast, widely supported and considered secure. SHA-512 produces a longer digest and can be faster on 64-bit hardware for large inputs, so it is a fine choice when you specifically want a 512-bit value. Avoid SHA-1 for anything security-related, since practical collision attacks against it exist. Use SHA-384 or SHA-512 when a standard or protocol explicitly requires them.
Why is there no MD5 option?
MD5 is cryptographically broken — attackers can produce two different inputs with the same MD5 hash quite cheaply — and the browser's Web Crypto API deliberately does not offer it. Adding MD5 would require bundling third-party code, which would break this tool's zero-dependency, fully-local design. For checksums and security you should use SHA-256 or stronger anyway, so MD5 is omitted on purpose.
Can I get the original text back from a hash?
No. Cryptographic hashing is a one-way function: it deterministically maps any input to a fixed-length fingerprint, but there is no reverse operation. The only way to "crack" a hash is to guess inputs and hash them until one matches, which is why hashes are used to verify data without storing or revealing it. This tool only computes hashes; it cannot reverse them.
Will these hashes match my command line or library?
Yes, as long as the input bytes are identical. This tool hashes the UTF-8 encoding of your text, which is what tools like sha256sum, OpenSSL and most programming libraries use by default for UTF-8 text. A classic check: the SHA-256 of "abc" is ba7816bf…f20015ad, matching every standards-compliant implementation. Differences usually come from trailing newlines or different character encodings.
Is my text uploaded anywhere?
No. All hashing happens in your browser through the native Web Crypto API, with no network requests. Your text is never sent to a server, stored or logged, so you can safely hash passwords, secrets or private documents to compare fingerprints. Close the tab and nothing is retained anywhere.
Can two different texts produce the same hash?
In principle, yes: inputs are unlimited and outputs are fixed-length, so collisions must exist mathematically. In practice it depends on the algorithm. For MD5 and SHA-1, researchers can manufacture colliding inputs on demand, which is why both are retired from security use. For SHA-256, no collision has ever been found; with 2^256 possible outputs, a brute-force search would need around 2^128 attempts, far beyond any conceivable computing effort.
Is SHA-256 suitable for storing passwords?
On its own, no. SHA-256 is fast by design, and fast is exactly wrong for password storage, because attackers with a leaked database can test billions of candidate passwords per second on GPUs. Password storage needs a slow, salted key-derivation function such as bcrypt, scrypt or Argon2, which stretches each guess into a deliberately expensive computation. SHA-256 is the right tool for integrity checks and fingerprints, not for protecting stored credentials.