Hash Generator

How it works

A cryptographic hash function takes an input of any length — a single character, a 4 GB disk image — and returns a fixed-size string of bytes called a digest. The same input always produces the same digest, on every machine and in every implementation, and changing even one bit of the input produces a completely different, unpredictable result. That last property, usually called the avalanche effect, is what makes a digest useful as a fingerprint: nobody can quietly edit a file and keep the hash.

This page hands your input to crypto.subtle.digest(), the Web Crypto implementation that ships with the browser. Text is converted to bytes with TextEncoder, which always emits UTF-8 without a byte-order mark; a file is read as an ArrayBuffer through the File API, so the digest covers the exact bytes on disk, including things an editor hides such as CRLF line endings. Because digest() is asynchronous, the button reports a computing… state and stays disabled until all four algorithms have finished. The result is shown as lowercase hexadecimal — two characters per byte, which is why SHA-256 is always exactly 64 characters and SHA-512 exactly 128.

The four algorithms are members of the same SHA-2 family, standardised in NIST FIPS 180-4, plus the older SHA-1. They differ only in output size and internal word size: SHA-1 produces 160 bits, SHA-256 produces 256, and SHA-384 and SHA-512 are truncated and distinct variants of the 512-bit construction. Larger output means a larger space an attacker has to search, but for ordinary integrity checks SHA-256 already offers a comfortable margin. All four are computed here in a single pass over one input, which is handy when a download page lists several checksums and you are not sure which one you will be asked for.

What hashing does not do

The limits matter more than the mechanics, so here they are plainly. Hashing is not encryption. There is no key and no decryption step; the tool cannot reverse a hash, and no other tool can either for any input that is not trivially guessable. If you need to recover the original data, hash the wrong primitive — use encryption with a key you can manage.

• SHA-1 is no longer collision-safe. Chosen-prefix collisions have been demonstrated publicly, which means two different inputs can be crafted to produce the same SHA-1 digest. It is still adequate for spotting accidental corruption, but it must not be used for signatures, certificates or anything an adversary has an incentive to forge. MD5, the other hash you will still meet in the wild, is broken even more thoroughly and should be treated the same way.
• SHA-2 needs correct usage, not just a correct algorithm. A digest proves that two byte sequences are identical. It does not prove who produced them. If you need to know that a message came from a particular party and was not altered on the way, you need a keyed construction — HMAC, or a digital signature — rather than a bare hash.
• Fast hashes are the wrong tool for passwords. SHA-256 is designed to be quick, which is exactly what a password cracker wants. Password storage needs a salted, deliberately slow function such as Argon2id, scrypt, bcrypt or PBKDF2, with a per-user salt and a tuned work factor.
• A matching hash is not a proof of safety. Comparing a digest tells you the bytes are the same as the ones that produced the expected value. If the expected value itself came from a compromised source, or was published alongside a malicious file, the match means nothing.
• The environment has to cooperate. Web Crypto is only exposed in a secure context, so the page needs HTTPS or a localhost origin. In an insecure context the tool says so instead of failing silently, and very large files are limited mainly by how much memory the browser will allocate.

How to use this tool

1. Pick exactly one input. Type or paste into the text box, or choose a file with the file button or by dragging it onto the dashed box. When a file is selected it takes precedence over the text, and Clear file and hash the text instead switches back.
2. Press Compute hashes. All four digests appear together for the same input, so you can compare against whichever checksum a vendor published. The button is disabled while the work is running and the status line reports the size of the input.
3. Copy the digest you need. Each row has its own copy button, and the UPPERCASE toggle reformats every digest on screen and in the clipboard. Hexadecimal case is purely cosmetic — a3f1 and A3F1 are the same bytes.
4. Compare against a known value. Paste the expected hash into the third section. The comparison ignores spaces, tabs and line breaks and is case-insensitive, then names the algorithm that matched — or tells you that none of the four did.
5. Mind the bytes, not the text. If a comparison fails unexpectedly, check the boring things first: an editor that appended a newline, a file saved as UTF-16 or with a BOM, a ZIP extracted with different line endings, or the wrong algorithm entirely.

As a quick check that everything works as advertised, hash the five characters hello in the text box. SHA-256 gives 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 — the same value any compatible tool will print, because the standard fixes the padding and the output, not the implementation.