Hash Generator

How to Generate and Verify a Hash

Features

What Is a Cryptographic Hash Function?

A hash function takes an input of any size — a single character, a paragraph, a 4 GB disk image — and always returns a fixed-length string called a digest. Flip a single bit anywhere in the input and the digest changes completely and unpredictably; cryptographers call this the avalanche effect. It is the reason hashes are useful for two very different jobs at once: proving a file has not been altered (integrity checking, which is what this tool is built for), and, when combined with a per-user salt and a deliberately slow algorithm, verifying a password without ever storing the original value.

Under the hood, this tool takes two different implementation paths depending on the algorithm. SHA-1, SHA-256, SHA-384 and SHA-512 are handed to crypto.subtle.digest(), the Web Crypto API built into every modern browser — a native, hardware-accelerated implementation, the same one responsible for the cryptography behind HTTPS itself. MD5 predates that API and isn't part of its specification, so it runs here as a pure JavaScript implementation of RFC 1321, operating directly on the raw bytes of your text or file rather than converting through a string first — which is also why it can hash arbitrary binary file content correctly, not just readable text.

For a deeper walkthrough of the avalanche effect, why MD5 needed a hand-written implementation here, and how file verification actually works, see: What Is SHA-256 Hashing and How Does It Work?.

Identifying an Unknown Hash by Its Length Alone

Every algorithm here produces an output of one, fixed length, and that length alone is enough to identify it — no metadata or label required. MD5 is always exactly 32 hexadecimal characters. SHA-1 is always 40. SHA-256 is 64, SHA-384 is 96, and SHA-512 is 128. This is precisely how the Verify feature in this tool works: paste a string, it counts the characters, and it knows which algorithm to compare against before it even looks at the value itself.

The same rule is useful well beyond this tool. If you ever find a "password hash" in a leaked database dump or a config file that is exactly 32 characters of hex, you are almost certainly looking at unsalted MD5 — a serious red flag regardless of context, since it means every identical password in that dataset produces the exact same stored value, and rainbow tables for common passwords are trivially available. A 60-character or longer string starting with $2b$ or $2a$, by contrast, is bcrypt, not a plain hash at all — see the Bcrypt Hash Generator for how that format actually works.

Who Actually Uses a Hash Generator

• Developers — confirming a downloaded dependency or Docker base image hasn't been tampered with before it enters a build pipeline
• System administrators — verifying an ISO or firmware image matches the checksum published on the vendor's site before flashing it to hardware
• QA and release engineers — confirming two build artifacts produced on different machines are byte-for-byte identical before shipping
• Security researchers — quickly identifying which algorithm an unlabeled hash from a sample or log file belongs to
• Students learning cryptography — seeing the avalanche effect directly by changing one character of input and watching every algorithm's output change completely
• Anyone sharing a large file over an unreliable connection — comparing a hash computed before and after transfer to confirm nothing got corrupted along the way

Real-World Verification Scenarios

Confirming a Linux ISO wasn't corrupted or tampered with. Distributions like Ubuntu and Debian publish a SHA-256SUMS file alongside every download. After downloading a multi-gigabyte ISO, switch this tool to the File tab, drop the ISO in, and paste the published SHA-256 string into Verify. A ✅ means the download is bit-for-bit identical to what the distribution actually released — a genuine protection against both network corruption and a compromised mirror serving a tampered file.

Proving two build artifacts are identical. A release engineer builds the same project on a CI server and on a local machine to rule out environment drift. Hashing both output files with SHA-256 and comparing the results takes seconds and gives a definitive yes-or-no answer, instead of spending time diffing binaries or trusting that "it looked the same."

Checking a file survived a flaky transfer. Someone copies a large archive over a USB drive with a history of dropping bytes on big transfers. Hashing the file before and after copying — and comparing the two SHA-256 values — confirms in seconds whether the copy is trustworthy, well before opening the archive reveals a corrupted entry the hard way.

The Mistake That Trips Up Almost Everyone: Hashing Is Not Encryption

Encryption is reversible by design — anyone holding the correct key can turn ciphertext back into the original plaintext. Hashing has no key and no reverse direction at all; there is no operation that turns a SHA-256 digest back into the text that produced it. That distinction is exactly why hashes are the right tool for "does this match what I expect" questions and the wrong tool for "I need to read this again later." If you actually need your original data back, you want encryption, not a hash — and if you need to inspect the contents of a token rather than just verify it, the JWT Decoder handles that different job.

Why Browser-Based Hashing Is Worth Trusting

Plenty of hash tools online quietly send your input to a server before returning a result — which is a real problem if what you're hashing is an API key, an internal file path, or a password you're double-checking against a freshly generated one before use. Nothing you type or upload here is ever transmitted anywhere. SHA-1 through SHA-512 run on the browser's native Web Crypto API and MD5 runs as local JavaScript — both execute entirely on your device, and you can confirm this yourself by disconnecting from the network after the page loads and watching the tool keep working exactly as before.

Tips for Getting Reliable Results

• Re-copy the full string if a Verify comparison fails. A single missing character from the end of a long hex string produces a mismatch that looks exactly like real corruption — copy the entire published checksum again rather than assuming the file is bad.
• Count characters when a hash arrives with no label. 32 characters is MD5, 40 is SHA-1, 64 is SHA-256, 96 is SHA-384, 128 is SHA-512 — you can identify any of these five formats on sight without opening this tool at all.
• Hide algorithms you don't need before using Copy All. Toggling off MD5 and SHA-1 keeps the copied text focused on the SHA-2 values you actually want to paste into a report or ticket.
• Expect MD5 to disappear on large files. Files over roughly 60 MB skip MD5 automatically to protect the tab from freezing — this is intentional, not a bug, and SHA-256/384/512 remain fully available regardless of file size.
• Never hash a password directly for storage. If you're building something that stores credentials, use the Bcrypt Hash Generator instead — a raw SHA-256 or MD5 digest has no salt and can be brute-forced far too quickly.
• Keep large-file work on desktop where possible. The whole file has to fit in browser memory before it can be hashed, so a phone with limited RAM will struggle with files a laptop handles easily.

When This Tool Is the Wrong Choice

Skip this tool if you need to store user passwords (use bcrypt or Argon2, never a raw hash — see the Bcrypt Hash Generator), if you need reversible confidentiality for a message rather than a fingerprint of it (use AES encryption instead), or if you routinely need to checksum files well beyond 500 MB, where a native command-line tool avoids the memory ceiling a browser tab imposes. For everyday integrity checks, quick checksums, and comparing a file against a published hash, everything here runs locally and instantly with nothing to install.