b2KIT

Hash Verifier

Verify file or text integrity by comparing computed hash values against expected hash digests.

Tested tool guide Tested browser tools Checked August 16, 2026

What Hash Verifier does, with a checked example

This tool computes a cryptographic hash of text you paste or a file you select, then compares the digest against the one you supply and reports a match or a mismatch. A hash is a fixed-length fingerprint: identical bytes always produce the same digest, and any single changed byte produces a completely different one. The result users most often get wrong is the byte boundary. The hash covers exactly the bytes you gave the tool, so a trailing newline, a line-ending conversion, or a Unicode normalization difference yields a different digest even when the content looks identical on screen.

Worked example

A concrete input and expected output from the current implementation.

Input

Text: abc | Algorithm: SHA-256 | Expected digest: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Expected output

Computed: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. Result: match.

The string "abc" is the standard SHA-256 test vector from FIPS 180-4, and its digest is exactly the value shown, so the comparison reports a match. The same text with a trailing newline, or any other expected digest, would report a mismatch.

How the result is produced

1

One-way fingerprints

Every digest is computed from the input bytes alone and cannot be reversed into the content it came from. The comparison is a pure equality check between the digest you pasted and the digest the tool computed; hex digits are case-insensitive, so upper- and lowercase forms of the same digest compare equal. Digest length identifies the algorithm: 32 characters is MD5, 40 is SHA-1, 64 is SHA-256, 128 is SHA-512.

2

Exact bytes, exact result

Text is hashed as its encoded bytes, so the same words can hash differently depending on how they are stored: a trailing newline, CRLF versus LF line endings, a byte order mark, or composed versus decomposed accented characters all change the byte stream. Files are hashed as the raw bytes on disk, and re-saving a file with a different editor or setting produces a different stream even when what you see is unchanged.

Good uses

  • After downloading an installer, ISO, or firmware image, check its digest against the SHA-256 published on the vendor's download page before running it.
  • Confirm that two copies of the same file are byte-identical after copying it to a USB drive, external disk, or cloud service, instead of eyeballing file sizes.
  • Verify that a large file survived a slow or interrupted transfer intact, or find duplicate files on disk by comparing digests rather than contents.

Limits and checks

  • A match proves byte identity, not safety. Malware has a valid hash too: if the digest was published for a malicious file, the match only confirms you received exactly that file. Verification never establishes authenticity or trustworthiness of the content.
  • MD5 and SHA-1 are not collision-resistant, so for content that might be adversarial, prefer SHA-256 or SHA-512. MD5 remains acceptable for casual error detection, but not as a security control.
  • Mismatches are usually content drift, not corruption: a trailing newline, a line-ending conversion, or a re-saved file with different encoding settings changes the digest. Re-hash the exact artifact you downloaded and check that the algorithm matches the digest length.

Common questions

Why does my digest not match the one the command line shows?

Most often a trailing newline: `echo hello | md5sum` hashes 'hello' plus a newline, while pasting 'hello' into the tool hashes exactly five characters. Use `printf 'hello' | md5sum` or `echo -n` for newline-free input, or hash the same file on both sides. Windows files saved with CRLF endings cause the same kind of mismatch.

Does a matching hash mean the file is safe to run?

No. A match means the bytes you have are exactly the bytes the digest was computed from. If you took the digest from a channel the publisher controls, that is strong evidence of intact delivery; it says nothing about whether the content itself is benign, so malware with a published digest still matches. Verify the digest's source as carefully as the file.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools