Skip to content
Control Plane Labs

Hash Generator

CRC32, MD5, SHA-1, SHA-256, SHA-384, SHA-512 and HMAC over text or a local file. Hex or base64 output, computed in your browser.

Privacy: Hashing happens in your browser: SHA and HMAC via crypto.subtle, MD5 and CRC32 in a local module. Files are read with FileReader and never uploaded, and the HMAC key is never written to the URL.

AlgorithmDigest (hex)
Nothing to hash yet.

SHA-1, SHA-256, SHA-384 and SHA-512 come from crypto.subtle, your browser's native implementation; HMAC uses the same API with an imported raw key. CRC32 and MD5 are computed by a small local module because Web Crypto deliberately does not offer them. Nothing is uploaded: file bytes are read with FileReader and stay in the tab, and the HMAC key is kept out of the URL. Text input is mirrored to the URL up to 2 KB — clear the box before sharing a link if the input is sensitive.

What it does

Paste text or pick a file and get every common digest at once: CRC32, MD5, SHA-1, SHA-256, SHA-384, and SHA-512, in hex or base64, with a copy button per row. Tick HMAC and supply a key to get keyed MACs of the same input instead. Files are read locally with FileReader, with a progress bar for the read, and nothing is ever uploaded — which is the whole point of doing this in a browser tab rather than pasting a customer artifact into someone’s web service.

The weak algorithms are labeled in the table rather than quietly offered alongside the strong ones. CRC32 is a checksum, MD5 has been collision-broken since 2004, and SHA-1 since 2017.

How it works

SHA-1, SHA-256, SHA-384, and SHA-512 come from crypto.subtle.digest, the browser’s native implementation of the algorithms specified in RFC 6234 (SHA-2) and RFC 3174 (SHA-1). HMAC uses the same API with a raw imported key and follows RFC 2104. Using the native implementation matters: it is constant-folded C++, it is what the platform security stack already trusts, and it will beat any JavaScript implementation on a large file by an order of magnitude.

MD5 and CRC32 are not in the Web Cryptography API and never will be — the specification only lists algorithms considered fit for purpose. So those two run in a small local module: MD5 per RFC 1321, CRC32 with the reflected 0xEDB88320 polynomial used by zip, gzip, and PNG. Both are verified against known test vectors. Expect them to be slower than the native digests on a multi-hundred-megabyte file.

Text input is hashed as UTF-8 bytes. If a digest here disagrees with one your shell produced, check the input bytes before suspecting the algorithm: echo without -n appends a newline, and that one byte changes everything.

Choosing an algorithm, honestly

For anything where an adversary can influence the input, use SHA-256. It is the default for a reason and there is no practical attack. SHA-512 is not more paranoid so much as differently shaped — it is often faster than SHA-256 on 64-bit hardware because it works on 64-bit words, so it is a reasonable pick for hashing large local files. SHA-384 exists mostly because it is a truncated SHA-512 that resists length-extension, which is why it shows up in TLS cipher suites and in subresource integrity attributes.

MD5 and SHA-1 remain acceptable for exactly one thing: detecting accidental corruption when something upstream already committed to them. A package index that publishes MD5 sums, a legacy ETag, an old vendor API that signs with HMAC-MD5. They are not acceptable for signatures, certificates, or verifying a download against a source you do not control, because a collision means two different files share a digest and the SHAttered team demonstrated exactly that for SHA-1 with a pair of PDFs.

Neither belongs anywhere near password storage — but neither does SHA-256. Fast hashes are the wrong tool there; you want bcrypt, scrypt, or Argon2, which are slow by design.

One more trap worth naming: do not build your own MAC by concatenating a secret with a message and hashing it. Merkle–Damgård constructions like SHA-256 are vulnerable to length extension, so SHA256(secret || message) lets an attacker append data and produce a valid digest without ever learning the secret. HMAC’s two-pass nested structure exists specifically to prevent that, and comparing MACs needs a constant-time equality check rather than ===.

When to reach for it

Verifying a downloaded release against the published checksum before you run it. Confirming a file survived a transfer intact. Reproducing the signature your webhook handler is rejecting, by HMAC-ing the raw request body with the shared secret and comparing byte for byte. Generating a content hash for a cache key. Checking whether two files that look identical actually are.

Frequently asked questions

Is it safe to still use MD5 or SHA-1?+
Only as a non-security checksum for detecting accidental corruption, and only when something you cannot change already uses them. Practical MD5 collisions have existed since 2004, and SHA-1 fell to the SHAttered attack in 2017 with a real colliding PDF pair; chosen-prefix SHA-1 collisions followed in 2020. That means neither can be used for signatures, certificates, content-addressed deduplication where an attacker controls input, or "this file is the file I expected" verification against a hostile source. Use SHA-256 unless something forces your hand.
Why is MD5 not in <code>crypto.subtle</code>?+
Because the Web Crypto specification only lists algorithms considered fit for purpose, and MD5 was excluded deliberately. Browsers will not add it. SHA-1 is exposed for digest() but not for signature verification, for the same reason. That is why MD5 and CRC32 here run in a small hand-written module rather than through the native API — and why they are noticeably slower on a large file.
The hex digest of the same string differs from what my server produced. Why?+
Almost always an encoding difference on the input, not a hashing difference. This tool hashes the UTF-8 bytes of what you typed. A shell pipeline usually appends a trailing newline (echo without -n), Windows tooling may hand over UTF-16 or a CRLF line ending, and a database column may be padded. Hash a file instead of pasted text when the bytes matter, and check for a stray 0x0a at the end first.
What is the difference between CRC32 and a hash?+
CRC32 is an error-detecting code built from polynomial division — it is what zip, gzip, and PNG use to notice bit rot. It is 32 bits, it is linear, and it is trivial to construct a second input with the same value, so it has no security properties at all. It is genuinely useful for spotting a truncated download or a flipped bit in transit, and useless for anything involving an adversary.
When should I use HMAC instead of hashing the secret and the message together?+
Whenever you are authenticating a message with a shared key. Naive constructions such as SHA256(secret || message) are vulnerable to length-extension against Merkle–Damgård hashes like SHA-256, letting an attacker append data and compute a valid digest without knowing the secret. HMAC's nested inner and outer hash with distinct padding is defined precisely to close that hole. It is what webhook signatures from Stripe, GitHub, and Slack use, and comparing the result requires a constant-time equality check, not ===.

Related tools

Password Strength and Breach Check

Local entropy estimate plus optional HIBP k-anonymity breach check. Your password never leaves the browser.

UUID Generator

Generate v4, time-ordered v7, and Nil UUIDs in bulk, in any format, and inspect an existing UUID for its version, variant, and embedded timestamp.

Base64 Encoder/Decoder

Encode and decode Base64 in your browser, with correct UTF-8 handling, a URL-safe alphabet toggle, and file mode for binary payloads.