Hash Verification — Free Online Tool

What is Hash Verification (Compare a Hash Against an Expected Value)?

Hash verification is the act of recomputing a digest from data you hold and checking it against the digest you were told to expect — if the two agree, the data is byte-for-byte what the publisher hashed. This tool does both halves in one place: pick an algorithm, paste your text and the expected value, and it reports a plain Match or No match instead of leaving you to compare 128 hex characters by eye.

• Six algorithms to choose from: SHA-256 is selected by default, with SHA-1, SHA-384, SHA-512, MD5 and CRC-32 also available. Algorithm choice is explicit rather than guessed from length, so you can catch the case where a value is the right width but the wrong function.
• Normalised comparison: Before comparing, the tool lowercases both sides, trims surrounding whitespace from the expected value and strips a leading 0x. That removes the representation differences that cause false mismatches — uppercase output from one tool, a prefixed CRC from another — without hiding real ones.
• Computed value stays visible: The digest of your input is always shown in its own field with a Copy button, even before you paste anything to compare. That means the tool doubles as a single-algorithm hash generator, and lets you paste the computed value into a ticket or a diff.
• Two independent status lines: One line reports the verdict — ✓ Match or ✗ No match — and prompts you when the expected field is still empty. A second reports whether computation succeeded. Nothing is ever silently blank.
• Same code paths as the other tools: SHA digests come from Web Crypto, MD5 from a bundled implementation, and CRC-32 from the same shared function the CRC32 Generator and Checksum Calculator use, so a value verified here matches what those tools produce for identical bytes.

Why use Hash Verification?

Reading long hex strings by eye is how bad comparisons happen: humans reliably check the first and last few characters and skip the middle, which is exactly where a substituted digest would differ. A mechanical comparison removes that failure mode.

• Eliminates eyeball errors: A SHA-512 digest is 128 characters. Comparing two of them visually feels thorough and is not — transposed or altered characters in the middle are almost invisible. A machine comparison is binary and honest about the result.
• Fixes formatting mismatches automatically: Digest text arrives uppercase from some tools, prefixed with 0x from others, with stray whitespace from copy-paste out of a PDF or a chat message. Those differences are cosmetic, and the tool normalises them so you spend your attention on real mismatches.
• Confirms which algorithm produced a value: If a 64-character digest fails as SHA-256, switching the selector lets you test other candidates quickly. Two tools disagreeing is often an algorithm confusion rather than corrupted data.
• Isolates encoding bugs during integration: When a partner's digest of "the same" payload does not match yours, verifying candidate strings here — with and without a trailing newline, with and without whitespace trimmed — pinpoints the byte difference far faster than reading code.
• Handles sensitive values safely: Verification runs in the page. Licence strings, internal identifiers and tokens are never placed in a request body or written to a server log.

When to use Hash Verification

Use it any time someone hands you a digest and says the data should match it.

• Checking a text snippet, config value or version string against a digest published in release notes, a changelog or a security advisory.
• Confirming that a value copied between systems — a ticket, a spreadsheet, a chat message, a scanned document — survived the trip unchanged.
• Debugging an API integration where the other side reports a digest mismatch, by testing candidate canonical forms until one matches.
• Working out which algorithm an undocumented digest came from, by holding the input fixed and cycling the algorithm selector.
• Validating test fixtures and migration scripts, so a hashed column in your test data really is the digest of the value it claims.
• Reproducing a legacy MD5 or CRC-32 value that an older tool or device produced, without adding a dependency to a modern codebase.
• Teaching or reviewing: showing that verification is a byte-exact comparison and that a near-miss is still a total failure.

How to use Hash Verification

Paste the data, pick the algorithm, paste the expected value. The verdict appears without a button press.

1. Paste the text to verify: Put the exact content in the Input box. If it came from a file or a shell command, check for a trailing newline — that single byte changes every digest.
2. Select the algorithm: Choose SHA-256, SHA-1, SHA-384, SHA-512, MD5 or CRC-32 from the Algorithm dropdown. Match whatever the publisher documented; if you do not know, the expected value's length narrows it down — 8 characters is CRC-32, 32 is MD5, 40 is SHA-1, 64 is SHA-256, 96 is SHA-384, 128 is SHA-512.
3. Paste the expected hash: Drop the reference digest into the Expected hash field. Case, surrounding whitespace and a leading 0x are all handled for you, so paste it as you received it.
4. Read the verdict: ✓ Match means the digests are identical after normalisation. ✗ No match means they are not — and there is no partial credit, since one differing bit produces a completely different digest.
5. Copy the computed value if you need it: The Computed hash field always shows your digest with its own Copy button, whether or not an expected value is present. Leave the expected field empty to use the tool as a plain single-algorithm generator.
6. Investigate a mismatch systematically: Try the other algorithms first, then vary the input: strip a trailing newline, trim whitespace, or convert CRLF to LF. If it still fails, the data genuinely differs from what was hashed.

Key features

• Six algorithms in one selector: SHA-256, SHA-1, SHA-384, SHA-512, MD5 and CRC-32, switchable without retyping the input or the expected value.
• Case-insensitive, prefix-tolerant matching: Both sides are lowercased, the expected value is trimmed and a leading 0x is removed, so cosmetic formatting never causes a false mismatch.
• Unambiguous verdict: A dedicated result line shows ✓ Match or ✗ No match, and prompts you when the expected field is still empty rather than implying success.
• Computed digest always shown: The digest of your input is displayed with a Copy button at all times, so the tool works as a generator as well as a checker.
• Live recomputation: Editing the input or the expected value, or changing the algorithm, re-runs the comparison automatically about 150 ms later.
• No uploads: Web Crypto plus bundled MD5 and CRC-32 implementations mean everything happens in the browser tab, with no network request.

Common use cases

• Release and advisory checks: Verify a snippet, manifest line or version string against the digest a vendor or security advisory published.
• Integration debugging: Find out why a partner's digest of your payload differs by testing candidate canonical forms until one matches theirs.
• Algorithm identification: Cycle the selector against a fixed input to determine which function produced an undocumented digest.
• Legacy compatibility: Reproduce and confirm MD5 or CRC-32 values from older devices, licence checks and desktop applications.
• Data-entry validation: Confirm that a value re-keyed or re-copied between systems is identical to the original, not merely similar.
• Test and fixture review: Check that hashed values committed in test data really correspond to the plaintext they document.

Examples

Each row shows the input, the algorithm, the expected value as you might receive it, and the verdict. All digests were computed from the exact bytes shown.

Input: hello world
Algorithm: SHA-256
Expected: b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

Computed: b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
Result: ✓ Match

Input: hello world
Algorithm: SHA-256
Expected: B94D27B9934D3E08A52E52D7DA7DABFAC484EFE37A5380EE9088F7ACE2EFCDE9 

Computed: b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
Result: ✓ Match

Input: hello world (with a trailing newline)
Algorithm: SHA-256
Expected: b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

Computed: a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447
Result: ✗ No match

Input: hello world
Algorithm: SHA-256
Expected: 5eb63bbbe01eeed093cb22bb8f5acdc3

Computed: b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
Result: ✗ No match

Input: hello world
Algorithm: CRC-32
Expected: 0x0d4a1185

Computed: 0d4a1185
Result: ✓ Match

Technical reference

What each option compares, and how the comparison is normalised:

MD5

128-bit digest — 32 hex characters. RFC 1321. Broken for collisions; acceptable only for matching legacy values over trusted data.

SHA-1

160-bit digest — 40 hex characters. FIPS 180-4. Collisions demonstrated in 2017; NIST is retiring it for all applications by 31 December 2030.

SHA-256

256-bit digest — 64 hex characters. FIPS 180-4. The default and the right choice for new verification workflows.

SHA-384

384-bit digest — 96 hex characters. A truncated SHA-512, so it also resists length-extension.

SHA-512

512-bit digest — 128 hex characters. Often the fastest SHA-2 variant on 64-bit CPUs.

CRC-32

32-bit checksum — 8 hex characters, IEEE 802.3 parameters. Error detection only; a match proves nothing against deliberate modification.

Normalisation applied

Computed value lowercased; expected value trimmed, lowercased and stripped of a leading 0x. Nothing else is altered.

Comparison type

Exact string equality after normalisation — a single differing character is a No match

Input encoding

UTF-8 via TextEncoder, so multi-byte characters are hashed as the bytes a file would contain

Common mistakes to avoid

Getting the expected digest from the same place as the data

Why it happens: Verification only proves that the data matches the reference value. If an attacker who replaced a download could also edit the checksum shown next to it — the same web page, the same compromised mirror, the same unauthenticated HTTP response — then both sides move together and the check always passes. This is the single most common way checksum verification provides reassurance without providing security, and it is why distributions sign their checksum files rather than merely publishing them.

How to avoid it: Obtain the expected digest through a channel independent of the data: a signed manifest, an HTTPS page on the vendor's own domain rather than a mirror, a package signature, a value recorded in your own lockfile before the artefact was cached. Verify the signature on the checksum file where one exists. If the digest and the data can only ever come from one place, treat a match as evidence against accidental corruption only.

Trusting a CRC-32 match as proof of integrity

Why it happens: CRC-32 is a linear error-detection code with only 2^32 possible values. Given any target checksum, an attacker can compute bytes to append or flip that force it, in microseconds and without brute force, and accidental collisions appear after roughly 77,000 random inputs. So a CRC-32 match tells you the data probably was not garbled in transit; it tells you nothing whatsoever about whether it was deliberately changed. The same reasoning applies, less dramatically, to MD5 and SHA-1 where collisions are concerned.

How to avoid it: Choose the algorithm to match the threat. CRC-32 for accidental damage over trusted channels; SHA-256 or better when the data crosses a trust boundary. If you also need to know who produced the data, a digest is not enough at all — use HMAC-SHA-256 with a shared secret, or a digital signature, so the expected value cannot be recomputed by whoever modified the content.

Concluding the algorithm is wrong when the input is wrong

Why it happens: A failed verification says the bytes differ, and people usually suspect the function first because it is the visible variable. In practice the input is almost always at fault: a trailing newline added by echo or an editor, CRLF line endings from a Windows checkout, a UTF-8 byte-order mark at the start of a file, leading or trailing whitespace from a copy-paste, or smart quotes substituted by a word processor. Each produces a completely unrelated digest with no hint of the cause.

How to avoid it: Check the byte count first — the status line and the input tools here let you copy and download exactly what was hashed, so you can inspect it in a hex viewer. Then vary one thing at a time: remove a trailing newline, trim whitespace, normalise line endings. Only after the input is pinned down should you cycle the algorithm selector, and remember that the expected value's length rules out most candidates immediately.

Comparing a Base64 digest against a hex one

Why it happens: The same 32-byte SHA-256 digest is 64 hex characters or 44 Base64 characters, and plenty of systems — Subresource Integrity attributes, S3 ETags for multipart uploads, several cloud APIs — publish Base64. Pasting a Base64 value into a hex comparison always fails, and the failure looks like corrupted data rather than a format difference. A value of 44 characters ending in = is the giveaway, as is the presence of + / or uppercase-and-lowercase mixing that hex never produces.

How to avoid it: Identify the encoding from the length and character set before comparing. Convert Base64 to hex with the Base64 tool here, or decode both sides to bytes and compare those. For Subresource Integrity strings, strip the sha256- prefix first. When you control the format, document which encoding you publish, and prefer comparing decoded bytes so representation can never cause a false negative.

Assuming a browser comparison is safe for server-side authentication

Why it happens: This tool does a plain string comparison, which is exactly right for a developer checking a value by hand and exactly wrong inside a request handler. Ordinary comparison short-circuits at the first differing character, so its runtime leaks how much of a submitted value was correct — enough for an attacker who can send many requests to recover a valid token or signature byte by byte. The vulnerability lives in the comparison, so it survives a perfectly good hash function.

How to avoid it: Never copy this interaction model into code that validates attacker-supplied digests, tokens or signatures. Use crypto.timingSafeEqual in Node.js, hash_equals in PHP, hmac.compare_digest in Python or subtle.ConstantTimeCompare in Go, decoding both sides to equal-length byte arrays first. For authenticity rather than integrity, verify an HMAC or signature rather than comparing a bare digest at all.

Frequently asked questions

How do I verify a hash matches?

Recompute the digest from the data you hold with the same algorithm the publisher used, then compare it character for character against the expected value. Paste the data into the Input box here, choose the algorithm, paste the reference digest into Expected hash, and read the verdict — the tool lowercases both sides, trims whitespace and strips a leading 0x so cosmetic differences do not produce a false mismatch. A match means the bytes are identical to what was hashed. It does not, by itself, mean the data is trustworthy: that also depends on where the expected digest came from.

What does it mean if the hash does not match?

It means the bytes you hashed are not the bytes that produced the expected digest — there is no partial match, because a single changed bit rewrites the whole output. The likely causes, in order: a trailing newline or different line endings, a different algorithm than you selected, whitespace or a byte-order mark you cannot see, a Base64 value compared against hex, an incomplete download or a truncated copy-paste, and only then genuine tampering. Check the input's byte count and try the neighbouring algorithms before assuming anything malicious.

How do I know which hash algorithm a digest came from?

Start with its length in hex characters: 8 is CRC-32, 32 is MD5, 40 is SHA-1, 64 is SHA-256, 96 is SHA-384 and 128 is SHA-512. Length narrows it but does not settle it — SHA3-256, BLAKE2s-256 and several others are also 64 characters — so confirm by hashing a known input and comparing. That is what the algorithm selector here is for: hold the input fixed and cycle through the options until one matches. If the value is 44 characters and ends with =, it is Base64 rather than hex, most likely of a 32-byte SHA-256 digest.

Is a matching MD5 or SHA-1 hash good enough?

It depends on who could have altered the data. Both algorithms are broken for collision resistance: MD5 collisions take seconds on ordinary hardware, and SHA-1 collisions were demonstrated in 2017 with chosen-prefix collisions following in 2020 for around US$45,000 of rented GPU time. That means an attacker who controls the content can produce two files with the same digest. If the data comes from a source you trust and you are only guarding against corruption, a match is meaningful. If the data crosses a trust boundary, insist on SHA-256 or better.

Can I verify a file's checksum here?

This page hashes typed or pasted text, so it is right for snippets, config values, version strings and API payloads. For an actual file, use the Checksum Calculator, which reads the file as raw bytes and computes SHA-1, SHA-256, SHA-384, SHA-512 and CRC-32 in one pass — then compare the relevant digest against your expected value. Hashing a file's contents pasted as text is not equivalent: line-ending conversion, encoding changes and a trailing newline added by your editor all alter the bytes, which is exactly what produces the mismatches people spend hours chasing.

Does the case of a hash value matter?

Not for meaning, only for naive comparison. A digest is a sequence of bytes; hex is a rendering of it, and B94D27B9 and b94d27b9 are the same byte. Some tools emit uppercase, some lowercase, some add a 0x prefix and some group with colons. This tool normalises all of that before comparing, so you can paste a value exactly as you received it. In your own code, lowercase both sides and strip prefixes and separators before comparing — or better, decode both to bytes and compare those, which removes the question entirely.

Why does the same text give a different hash in the terminal?

Usually because the terminal hashed extra bytes. echo appends a newline unless you pass -n, so echo hello | sha256sum hashes six bytes, not five; use printf '%s' hello instead. Other causes are a file's final newline, CRLF line endings on Windows, a UTF-8 byte-order mark, and shell quoting that altered the string. Verify by comparing lengths: the status line here reports the character count, and wc -c reports the byte count on the command line. Once the counts agree, the digests almost always do too.

References

• FIPS 180-4 — Secure Hash Standard (SHS)
• RFC 6151 — Updated Security Considerations for MD5 and HMAC-MD5
• SHA-1 is a Shambles — first chosen-prefix collision on SHA-1
• MDN — SubtleCrypto.digest()
• Node.js crypto — timingSafeEqual()