Free hash generator

A cryptographic hash function takes any input — a word, a paragraph, or a multi-gigabyte file — and produces a fixed-length string of letters and numbers called a hash (or “digest”, or “checksum”). The same input always produces the exact same hash, and even a one-character change in the input produces a completely different hash. This makes hashing useful for three very different jobs: verifying that a file wasn't corrupted or tampered with, storing passwords without keeping the actual password, and quickly telling two large pieces of data apart without comparing them byte by byte.

A hash is not encryption. Encryption is reversible — you can decrypt ciphertext back into the original data if you have the key. Hashing is one-way: there is no way to reconstruct the original input from its hash. That is exactly what makes hashes useful for integrity checks and password storage — the hash proves the input matches without ever exposing the input itself.

This tool generates six different algorithms side by side, because each one serves a different purpose depending on what you're protecting against — or whether you're protecting against anything at all:

If you just need to confirm a file downloaded correctly, any of these will tell you that. If you're protecting something security-sensitive — a password, a code signature, a legal record — use SHA-256, SHA-384, or SHA-512, and treat MD5, SHA-1, and CRC32 as unsuitable.

SHA-384 is part of the same SHA-2 family as SHA-256 and SHA-512 — it's actually computed with the SHA-512 algorithm internally, just with different initial values and a truncated 384-bit output. It shows up most often in TLS cipher suites (e.g. ECDHE-RSA-AES256-GCM-SHA384) and in some JWT signing algorithms (RS384, ES384), where it offers a security margin between SHA-256 and SHA-512 without SHA-512's full 128-character output.

CRC32 is a completely different kind of algorithm, and it does not belong in the same category as the SHA family or MD5. CRC32 is a cyclic redundancy check — it was designed purely to catch accidental corruption (a flipped bit from a bad disk sector, a truncated download, a noisy network link), not to resist a deliberate attacker. It is fast, produces a short 8-character output, and is what you'll see inside .zip and .gzip file headers and in Ethernet frame checksums. Because it's trivial to construct two different inputs with the same CRC32 value on purpose, never use it anywhere a malicious actor might benefit from forging a match — that's a job for SHA-256 or SHA-512.

A plain hash (MD5, SHA-256, etc.) proves that data hasn't changed, but it proves nothing about who produced it — anyone can hash a message and get the same result. HMAC (Hash-based Message Authentication Code) fixes that by mixing a shared secret key into the hashing process. The result is a value that only someone who knows the key could have produced, which is what makes HMAC suitable for authenticating a message, not just checking its integrity.

Turn on “Use secret key (HMAC)” above, enter the shared key, and the tool computes HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 using the browser's native crypto.subtle.sign. MD5 and CRC32 are hidden in HMAC mode because they aren't supported as MAC algorithms by the Web Crypto API and aren't appropriate for this use case.

HMAC shows up constantly in everyday API and webhook work:

• Signing API requests. Many APIs (AWS, payment processors, exchanges) require you to sign each request with HMAC-SHA-256 using your secret API key so the server can confirm the request wasn't tampered with and really came from you.
• Verifying webhook payloads. Services like Stripe and GitHub sign outgoing webhooks with HMAC so your endpoint can confirm the payload actually came from them and wasn't forged by a third party.
• Session and token integrity. JWTs signed with an HS256/HS384/HS512 algorithm are HMAC-signed tokens — this tool lets you compute and sanity-check that signature manually.

Paste your message (text or a file) and your shared secret, and compare the output against the signature you received — a match confirms both the message integrity and that it was signed with the correct key.

MD5 was designed in 1991 and was the internet's default hash for over a decade. It is now considered cryptographically broken. Researchers have demonstrated practical collision attacks — deliberately crafting two different inputs that produce the identical MD5 hash — since 2004, and modern hardware can generate an MD5 collision in seconds. That means an attacker can create a malicious file with the exact same MD5 hash as a legitimate one, which completely defeats MD5 as a security guarantee. The same is true, to a lesser but still serious degree, for SHA-1: Google and CWI Amsterdam published a real SHA-1 collision in 2017 (“SHAttered”), and major browsers and certificate authorities have since retired it.

So MD5 should never be used to hash passwords, sign software, verify certificates, or protect anything where an adversary might want to forge a match. For those cases, use SHA-256 or SHA-512 — and for password storage specifically, use a dedicated password-hashing algorithm like bcrypt, scrypt, or Argon2, not a raw hash at all, since general-purpose hashes are deliberately fast and therefore easy to brute-force.

That said, MD5 is still perfectly fine for non-adversarial integrity checks — confirming a file wasn't corrupted during a transfer, deduplicating files, or checking a cache key. Nobody is trying to forge a collision against your local backup script. Many tools and mirrors still publish MD5 checksums purely out of habit or legacy tooling, and that usage is harmless. The rule of thumb: if a malicious actor benefits from forging a matching hash, don't use MD5 or SHA-1 — use SHA-256 or SHA-512 instead.

No — and this is the single most common misconception about hashing. Hashing is not encryption. Encryption is designed to be reversible: with the right key, ciphertext turns back into the original plaintext. A cryptographic hash is designed to be one-way — the algorithm deliberately throws information away as it compresses an input of any size down to a fixed-length output, so there is no mathematical operation that turns a hash back into the input that produced it. Any tool, site, or service that claims to “decrypt MD5” or “decrypt SHA-256” is not actually reversing the hash — it's doing one of two things instead:

• Lookup against a precomputed table. Sites with huge databases of common passwords and their hashes (sometimes called rainbow tables) can instantly “crack” a hash if the original input was something predictable, like password123. This only works because the input was weak and already known — it doesn't work on random or unique data.
• Brute force. Trying enormous numbers of candidate inputs, hashing each one, and checking for a match. This is feasible for short or predictable inputs (a 4-digit PIN, a dictionary word) and completely infeasible for a long random string or a multi-megabyte file, where the search space is astronomically large.

The hash identifier panel in this tool leans into this honestly: given an unknown hash, it can tell you which algorithm probably produced it — based on the output length (32 hex characters usually means MD5 or NTLM, 64 means SHA-256, and so on), the character set, and recognizable prefixes like $2b$ for bcrypt or $argon2 for Argon2. That narrows down how the hash was made. It cannot, and does not claim to, tell you what input produced it — that would require reversing a one-way function, which is exactly what makes hashing useful for passwords and integrity checks in the first place.

Software publishers often post a hash (usually SHA-256) next to a download link so you can confirm the file you got is exactly the file they published — unmodified by a bad mirror, a man-in-the-middle, or a corrupted transfer. Here's how to check it:

1. Find the published hash. It's usually on the same download page, in a .sha256 / .md5 sidecar file, or in the release notes on GitHub.
2. Switch to File mode above and drop in the file you downloaded.
3. Paste the published hash into the Verify panel. The tool detects whether it's MD5, SHA-1, SHA-256, SHA-384, SHA-512, or CRC32 from its length automatically.
4. Check the badge. A green MATCH ✓ means the file is byte-for-byte identical to what the publisher hashed. A red NO MATCH ✗ means the file is different — re-download it from the original source before opening or installing it.

This comparison is case-insensitive, since some tools output hashes in uppercase and others in lowercase — the actual bytes are what matter, not the letter case.

Most free hash tools online only let you paste text into a box. That works for short strings, but it completely misses the most common real-world use case: verifying a file. This tool reads the file's raw bytes directly with the browser's File API and hashes the actual binary content — the same checksum you'd get from a command-line tool like certutil, shasum, or md5sum — not a hash of a filename or a text description of the file.

Because everything happens locally in your browser via FileReader and the native crypto.subtle API, there is no upload step, no file size limit imposed by a server, and no risk of a sensitive file — a private key, a legal document, a customer export — ever leaving your device. Large files simply take a little longer to hash locally; the tool shows a “Hashing…” state while it works through the bytes.

• Verifying software downloads. Confirm an installer or ISO matches the hash published by the vendor before you run it.
• Checking file integrity after a transfer. Hash a file before and after copying it over a network, USB drive, or cloud sync to confirm nothing got corrupted.
• Deduplicating files. Two files with the same hash are (for all practical purposes) identical, which is how many backup and sync tools detect duplicates without a byte-by-byte comparison.
• Generating cache keys or IDs. Developers hash file contents or request payloads to create stable, collision-resistant cache keys.
• Quick data-integrity spot checks. Confirm a config file, database export, or log archive hasn't silently changed between two points in time.
• Learning and teaching cryptography basics. Seeing how a single changed character completely scrambles the output hash is one of the fastest ways to understand the avalanche effect.
• Signing and verifying API requests or webhooks. Use HMAC mode with a shared secret to reproduce or sanity-check a signature from a payment provider, exchange, or webhook payload.
• Figuring out what kind of hash you're looking at. Found an unlabeled hash in a database dump, config file, or old script? The hash identifier narrows down the likely algorithm from its length and format.

Yes. Every hash and HMAC value — for both text and files — is computed entirely in your browser using the Web Crypto API (crypto.subtle.digest and crypto.subtle.sign) for SHA-1, SHA-256, SHA-384, and SHA-512, and compact, standards-compliant implementations for MD5 and CRC32, since neither is part of the Web Crypto API. Nothing you type or drop onto this page — including any HMAC secret key — is ever sent to a server, logged, or stored. That makes it safe to hash sensitive files, private keys, or confidential documents, and it means the tool keeps working even offline once the page has loaded.