Hash Generator — SHA-256, SHA-1 and SHA-512 Online
Hash any text with SHA-256, SHA-1 or SHA-512 using the browser's Web Crypto API. Every algorithm is computed at once and printed as lowercase hex, so you can compare digest lengths side by side. 100% client-side — nothing is sent to any server.
What is a cryptographic hash? A cryptographic hash function maps a message of any length to a fixed-length digest — 256 bits, written as 64 hexadecimal characters, for SHA-256. The same input always produces the same digest, a one-character change produces an unrecognisably different one, and no practical method exists to work backwards from a digest to the message. That one-way, fixed-length property is what makes hashes useful for integrity checks and fingerprints.
How to Use the Hash Generator
- Enter the message — Type or paste any text into the box. It is encoded as UTF-8 before hashing, so an accented character contributes two bytes and an emoji four — the digest of "café" is not the digest of "cafe".
- Highlight an algorithm — The four buttons choose which row is marked selected and given a coloured border. They do not restrict the calculation: every algorithm is computed on every run so you can see all the digests together.
-
Click Generate Hash — SHA-1, SHA-256 and SHA-512 are computed by
crypto.subtle.digest(), the browser's own implementation. Because that call is asynchronous, the status tag briefly reads Generating… before the rows appear. - Read the digest length — Each result is lowercase hex with one byte per two characters, so SHA-1 is 40 characters, SHA-256 is 64 and SHA-512 is 128. Length alone tells you which algorithm produced a hash you have been given.
- Copy a single row — The copy icon beside a row puts just that digest on the clipboard, with no algorithm label or whitespace, so it can be pasted straight into a comparison or a checksum file.
- Compare rather than eyeball — Never verify a hash by reading the first few characters. Paste both values into a comparison tool such as the Text Comparator, or use your terminal, so a mismatch in the middle cannot slip past.
How the Digests Are Computed
SHA-1, SHA-256 and SHA-512 are not implemented on this page. The text is passed through TextEncoder,
which produces a UTF-8 byte array, and that array is handed to crypto.subtle.digest() — part of the Web
Crypto API built into the browser. The returned ArrayBuffer is then formatted as hex, one zero-padded
two-character group per byte. Using the platform implementation matters: it is the same audited code the browser uses
for TLS, it runs natively rather than in JavaScript, and it produces the exact same digest as sha256sum,
certutil, Python's hashlib or OpenSSL for the same bytes.
All three SHA algorithms follow the same overall shape. The message is padded to a multiple of the block size, a 64-bit or 128-bit length field is appended, and the blocks are absorbed one at a time into a fixed-size internal state through a compression function run over many rounds. SHA-1 and SHA-256 work on 512-bit blocks with 32-bit words; SHA-512 uses 1024-bit blocks and 64-bit words, which is why it is often faster than SHA-256 on 64-bit hardware despite producing twice as much output.
The MD5 row on this page is not a usable MD5 digest. MD5 is not offered by the Web Crypto API,
so it is computed by a bundled JavaScript routine, and that routine's hex formatting is defective: it prints 128
characters with zero padding between the real bytes instead of the correct 32. Do not compare or publish it. For a
genuine MD5 use md5sum on Linux or macOS, or certutil -hashfile <file> MD5 on
Windows. The SHA-1, SHA-256 and SHA-512 rows are unaffected.
Algorithm Reference
| Algorithm | Digest size | Hex characters | Block size | Standing today |
|---|---|---|---|---|
| MD5 | 128 bits | 32 | 512 bits | Collisions are practical; unsuitable for any security purpose |
| SHA-1 | 160 bits | 40 | 512 bits | Collisions demonstrated in 2017; retained only for legacy verification |
| SHA-256 | 256 bits | 64 | 512 bits | The general-purpose default |
| SHA-512 | 512 bits | 128 | 1024 bits | Same family, larger margin, often faster on 64-bit CPUs |
SHA-256 and SHA-512 both belong to the SHA-2 family standardised in FIPS 180-4. SHA-3, standardised separately in FIPS 202, uses an entirely different sponge construction rather than the Merkle–Damgård design above; it is not a replacement forced by any weakness in SHA-2 but an independent alternative. The Web Crypto API does not expose SHA-3, which is why it is absent here.
Why collisions matter
A collision is two different messages with the same digest. Because a digest is fixed-length and messages are not, collisions must exist mathematically; the security question is whether anyone can find one. For MD5 that takes seconds on a laptop, and for SHA-1 a collision between two distinct PDF files was published in 2017. Once collisions are cheap, a signature over a digest no longer pins down a single document, so both algorithms are unacceptable for certificates, code signing or anything an attacker has an incentive to forge. Neither break lets anyone reverse a digest, which is why MD5 still appears in non-adversarial roles such as cache keys and deduplication.
What Hashing Does Not Do
Hashing is not encryption. Encryption is reversible with a key; a digest has no key and cannot be decrypted. If you need to recover the original data later, you want encryption, not a hash. The reason short inputs can still be "cracked" is that an attacker guesses candidates and hashes them until one matches — the digest itself was never reversed.
A bare hash is not password storage. SHA-256 is designed to be fast, and modern hardware can test billions of candidate passwords per second against a stolen digest. Password verification needs a deliberately slow, memory-hard function with a per-user random salt: Argon2id, scrypt, bcrypt or PBKDF2 with a high iteration count. Never store a plain SHA-256 of a password, and never paste a real password into any web page, including this one.
A hash alone does not prove who sent something. Anyone who can alter a file can recalculate its digest, so a checksum published next to a download only helps if it reaches you through a channel the attacker does not control. Authenticating a message requires a shared secret or a signature — that is what HMAC and public-key signatures are for, and it is a different problem from integrity.
Digests do not compress. A 3 GB video and the word "hello" both produce 64 hex characters under SHA-256. The digest is a fingerprint, not a summary: it identifies the input if you already have a copy to compare against, and carries no recoverable information about the content otherwise.
Frequently Asked Questions
SHA-256 unless you have a specific reason not to. It is the default for TLS certificates, Git object naming in newer repositories, container image digests and file checksums, and every platform implements it. Choose SHA-512 if you are on 64-bit hardware and want a larger margin — it is frequently faster than SHA-256 there. Treat SHA-1 and MD5 as read-only: use them to check a value someone else already produced, never to create a new one.
The hashing does not: crypto.subtle.digest() runs inside your browser and no request carries your message. One thing to be aware of is that pressing Generate also copies the message into the page URL so the result can be bookmarked or reloaded. Clear the box before sharing that link, and do not paste real passwords, keys or personal data into any online tool.
Because it is wrong. MD5 is not available through the Web Crypto API, so the page falls back to a JavaScript implementation whose hex formatting is broken — it emits 128 characters with zero padding rather than the correct 32. The underlying digest bytes are in there, but the printed string will not match any other tool. Use md5sum or certutil -hashfile <file> MD5 instead. SHA-1, SHA-256 and SHA-512 come from the browser and are correct.
Not on this page — the input is a text box, and pasting the contents of a binary file into it will not reproduce the file's checksum, because the browser re-encodes what you paste as UTF-8 text. To verify a download, use the command line: sha256sum file.iso on Linux, shasum -a 256 file.iso on macOS, or certutil -hashfile file.iso SHA256 on Windows.
Almost always because the bytes differ, not the algorithm. Check for a trailing newline — echo hello hashes a newline that a text box does not — and for character encoding, since this page always uses UTF-8 while some tools default to UTF-16 or a legacy code page. Invisible differences such as a non-breaking space, a BOM, or Windows CRLF versus Unix LF line endings will also change every digest.
A plain hash answers "has this data changed?" and anyone can compute it. An HMAC answers "did someone holding the shared secret produce this?", because it mixes a key into the calculation. Use a hash for checksums and fingerprints; use the HMAC Generator for webhook signature verification, API request signing and anything an attacker could otherwise recompute.
Yes, and it is worth knowing. Because SHA-2 uses the Merkle–Damgård construction, someone who knows hash(secret + message) and the length of the secret can compute a valid hash for message + padding + extra without knowing the secret. That is precisely why authentication should use HMAC, which is built to resist it, rather than a naive concatenation of a secret and a message.
It works offline once the page has loaded, since nothing is fetched at hash time. It does require a secure context, though: browsers expose crypto.subtle only over HTTPS or on localhost. Opened from a plain HTTP address or a file:// path, the SHA rows will report an error because the API is simply not defined.
In principle yes — 256 bits cannot uniquely represent every possible input — but no such pair has ever been found, and finding one by brute force would take on the order of 2^128 operations. Practically, treat a SHA-256 digest as a unique fingerprint. The distinction matters only for MD5 and SHA-1, where finding collisions is a demonstrated, affordable attack rather than a theoretical bound.
Use Cases
Checking a Published Checksum
A vendor lists a SHA-256 value beside a config snippet or licence text. Paste the text here, compare the two digests character for character, and you know whether what you received is byte-identical to what was published.
Reproducing a Backend Digest
When an API rejects your request signature, hash the exact payload string here and compare it with what your server logged, to find out whether the mismatch is in the data or in the signing step.
Identifying an Unlabelled Hash
Given a bare hex string from a log or a database column, count its characters — 40 means SHA-1, 64 SHA-256, 128 SHA-512 — then hash a candidate value here to confirm which algorithm the system used.
Building a Deterministic Cache Key
Turn a long query string or a rendering parameter set into a fixed-length key for a cache or a filename, so that identical inputs always resolve to the same entry regardless of how long the original was.
Demonstrating the Avalanche Effect
Change one character of the message and regenerate: roughly half the output bits flip. It is the clearest way to show a class why a digest cannot be used to guess how close a candidate input was.