Hash Calculator

Supported algorithms

Fourteen algorithms in three families: the SHA-2 family from FIPS 180-4, the SHA-3 family from FIPS 202, and three CRC checksums whose polynomials come from ISO/IEC 13239. The digest length determines how many characters you see — a hexadecimal digest has one character per four bits, so SHA-256 prints 64 and MD5 prints 32. That alone identifies which algorithm produced an unknown hash.

Worked examples

The digests below are the published test vectors from FIPS 180-4 and RFC 1321. Hashing the same input in this tool must reproduce them exactly — that is a useful check that any hash implementation, including this one, is behaving.

The empty-string digest is worth memorising the first few characters of. e3b0c442… appearing where you expected real content is the signature of a file that failed to read, an empty buffer, or a variable that was never assigned.

What is a hash function?

A hash function takes input of any size and produces a fixed-length string of characters — the hash, or digest. Hash "hello" with SHA-256 and you get 64 hexadecimal characters. Hash an entire film with the same algorithm and you still get 64 characters. The output looks random but is completely deterministic: the same input always produces the same hash, on any machine, in any programming language, forever.

Two other properties make hashes useful. They are one-way — given a hash, there is no practical way to recover the original input. And a good hash function has the avalanche property: change a single character of the input and roughly half the output bits flip. There is no partial similarity, so you cannot tell from two hashes whether their inputs were nearly identical.

Checksums versus cryptographic hashes

The two groups in the table above serve genuinely different purposes, and confusing them is a real mistake.

Checksums (CRC-8, CRC-16, CRC-32)

CRC stands for Cyclic Redundancy Check. These are designed to catch accidental corruption — a flipped bit from a bad cable, a truncated download, a scratched disc. They are fast and short, and they are used in Ethernet frames, ZIP archives, and PNG files. They are not secure: forging a different input with the same CRC is trivial, so never use one to verify that a file has not been tampered with deliberately.

Cryptographic hashes (MD5, SHA, RIPEMD)

These are built so that finding two inputs with the same hash is computationally infeasible. That makes them suitable for verifying downloads against a published digest, storing password verifiers, generating content addresses, and signing data.

Which algorithm should you use?

• SHA-256— the sensible default. Widely supported, thoroughly analyzed, and with no known practical weaknesses. If you are unsure, use this.
• SHA-512— a larger digest, and often faster than SHA-256 on 64-bit hardware because it operates on 64-bit words.
• SHA-3 family— a structurally different design (Keccak) selected by NIST in 2012. Its value is diversity: it would not fall to an attack that broke SHA-2.
• MD5— cryptographically broken. Collisions can be produced in seconds on a laptop. Still fine as a fast non-security checksum or cache key, but never for signatures, certificates, or integrity against an attacker.
• SHA-1— also broken. A practical collision was demonstrated in 2017, and browsers and certificate authorities have retired it. Treat it as legacy only.
• RIPEMD-160— a 160-bit digest developed in Europe, still used in Bitcoin address derivation.
• CRC-32— error detection only, never security.

Common uses

• Verifying downloads— projects publish a SHA-256 digest next to a release. Hash the file you received and compare. If the strings match exactly, your copy is byte-identical.
• Detecting duplicate files— identical hashes mean identical content, regardless of filename or timestamp.
• Confirming a transfer— hash a file before and after copying it across a network or onto external storage.
• Cache keys and content addressing— a digest makes a compact, unique identifier for a blob of data.
• Comparing configuration— hash two config files to see instantly whether they differ at all.

How much collision resistance a digest buys

Because inputs are unlimited and outputs are fixed, collisions must exist. What matters is how much work finding one takes. The birthday bound says an n-bit digest resists collision search to roughly 2^n/2 operations, not 2ⁿ — half the bits, in the exponent.

So SHA-256 offers 128 bits of collision resistance, and MD5 offers 64 — which was already uncomfortable before its structural weaknesses reduced the real figure far below that. This is also why a 32-bit CRC is no security control at all: 2¹⁶ is about 65,000 operations.

The same arithmetic governs truncation. Cutting a SHA-256 digest to its first 16 hexadecimal characters leaves 64 bits, and therefore 32 bits of collision resistance — roughly four billion operations, which is minutes of work. NIST SP 800-107r1 sets out when truncation is acceptable and how much security remains; the short answer is that a shortened digest is a shortened digest, not a compact one.

Why none of these belong in password storage

Hashing passwords with a plain function like SHA-256 is not secure, even though it is a strong algorithm. The problem is speed: SHA-256 is designed to be fast, so an attacker with a stolen database can test billions of candidate passwords per second on a GPU. The property that makes a hash good for file integrity is exactly what makes it bad here.

Verifying a download

This is the most common everyday use. A project publishes the SHA-256 of its installer; you hash the file you downloaded and compare. Rather than squinting at sixty-four characters, paste the published value into the Verify field and the tool reports a match or a mismatch. The comparison ignores case and surrounding whitespace, since published checksums are formatted inconsistently.

A mismatch means the bytes differ from what the publisher hashed — a truncated download, the wrong version, or in the worst case a tampered file. Note that this proves the file matches the checksum, not that the checksum itself is trustworthy: if an attacker controls the page showing both, they control both.

HMAC: hashing with a key

A plain hash proves a message has not changed; anyone can recompute it. An HMAC additionally proves who computed it, because reproducing the value requires a shared secret key. This is what signs webhook payloads and API requests — Stripe, GitHub and AWS all send an HMAC alongside the request so the receiver can confirm it came from the expected sender.

Enable Use a secret key in the configuration panel and supply the key. HMAC is available for MD5, RIPEMD-160, SHA-1 and the SHA-2 family. It is not offered for the CRC checksums, which have no key, nor for SHA-3 in this tool. Changing a single character of the key changes the entire result, which is the point.

HMAC is defined in RFC 2104 and FIPS 198-1. Its construction — hashing the key twice, with two different pads, around the message — is what makes it safe even on hash functions vulnerable to length-extension. That is why HMAC-MD5 remains unbroken despite MD5 itself being collidable: the attacks that break MD5 collisions do not carry over. RFC 6151 nonetheless advises against new deployments.

Output formats

Digests are shown as hexadecimal by default, optionally uppercase — some tools print ff and others FF for the same value, and neither is more correct. Base64 output is more compact and is what HTTP headers such as Content-Digest and Subresource Integrity attributes use. The All Algorithms table computes every supported digest of the current input at once, which is useful when you have a hash but do not know which algorithm produced it: match the length first, then compare.