A checksum comparator does one small job properly: deciding whether two digests are identical. That sounds trivial until you have actually done it — sixty-four hexadecimal characters, no word boundaries, no rhythm, usually in a font where 0 and O look similar. Human comparison of long hex strings is genuinely unreliable, and the failure mode is silent.
This tool compares the full string, reports how many characters differ and where the first difference falls, and can compute a digest from pasted text so you can verify a published value without a terminal. Arb Digital added it to the free developer toolset because verification that people skip because it is tedious is verification that is not happening.
What This Checksum Comparator Does
In its default mode it takes two checksums and compares them after normalising case and stripping whitespace, so a value copied from a checksum file with a filename after it compares cleanly against one copied from a web page. The verdict is unambiguous — match or no match — and the supporting figures tell you which algorithm was detected, the digest length in bits, how many characters differ, and the index of the first difference.
In the second mode you paste the source text alongside a published checksum, and the tool computes the digest itself and compares. MD5 is implemented directly in JavaScript; SHA-1 and SHA-256 use the browser's built-in Web Crypto interface. Nothing is uploaded in either mode.
How to Use It
- Choose a mode. Compare two existing checksums, or compute one from text and compare it against a published value.
- Leave the algorithm on auto unless you are computing from text, where you need to pick the algorithm the publisher used.
- Paste the values. Extra whitespace, mixed case, and a trailing filename are all handled.
- Read the verdict. A mismatch shows how many characters differ, which distinguishes a completely wrong value from a single mistyped character.
- Copy the report when you need to record the verification alongside a release or a support ticket.
The Formula / How It's Calculated
A cryptographic hash function maps input of any length to a fixed-length digest. The same input always produces the same digest, and changing a single bit of input changes roughly half the output bits — the avalanche property. That is what makes a digest useful for verification: any corruption, however small, produces a completely different value rather than a slightly different one.
MD5 produces 128 bits, written as 32 hexadecimal characters. SHA-1 produces 160 bits and 40 characters. SHA-256 produces 256 bits and 64 characters. Because those lengths are distinct, the algorithm can be inferred from a digest with no other information, which is what the auto-detect option does.
The comparison itself is a character-by-character equality test on the normalised strings. Counting the differing positions is more informative than a simple true or false: one differing character usually means a transcription error, while a value that differs in roughly half its characters is what you would expect from genuinely different input — which is the case worth investigating.
What a Matching Checksum Actually Proves
A match proves the bytes you have are the bytes that produced the published digest. It does not prove the file is safe, and it does not prove it came from who you think it did — unless the checksum itself arrived through a channel an attacker could not also control.
This is the weakness in the common pattern of publishing a download and its checksum on the same page. Anyone able to replace the file can replace the digest beside it, and the verification passes perfectly. The checksum in that arrangement protects against accidental corruption — a truncated download, a bad mirror, a flaky disk — and against nothing deliberate.
Real integrity guarantees come from signatures. A digest signed with a private key can be verified with the corresponding public key, which ties the file to a holder of that key rather than merely to whoever controls the page. When a project publishes both a checksum file and a signature over that file, verifying only the checksum uses half the protection offered.
Why MD5 and SHA-1 Are Still Fine Here and Not Elsewhere
Both MD5 and SHA-1 are broken for collision resistance. Practical attacks exist that produce two different inputs with the same digest, demonstrated publicly for SHA-1 in 2017 by the SHAttered collision research. That is fatal for signatures and certificates, where an attacker gets to influence both documents.
Detecting accidental corruption is a different threat model. A truncated download or a flipped bit will not accidentally land on a colliding value; the probability is negligible. So an MD5 checksum published beside a file remains a perfectly serviceable corruption check, which is why so many projects still publish one. What it cannot do is defend against an adversary who is choosing the content. For anything where that matters, SHA-256 is the current minimum, and NIST's hash function guidance sets out the approved family in detail.
Why Your Computed Digest Does Not Match
Assuming the source is genuine, mismatches almost always come from a difference in the exact bytes hashed rather than from a hash failure. The most common cause is a trailing newline: a file ending with a line break hashes differently from the same text without one, and pasting into a form frequently adds or removes one.
Line endings are the second cause. A text file with Windows-style carriage return and line feed pairs produces a different digest from the same file with Unix line feeds, and version control systems convert between them automatically on checkout. Character encoding is the third — the same visible text encoded as UTF-8 and as UTF-16 is entirely different bytes, and any non-ASCII character makes that visible.
This tool hashes exactly the characters in the text box, encoded as UTF-8, with no normalisation. If a digest computed here disagrees with one from a command line tool over what looks like the same text, compare byte counts before suspecting either implementation.
Verifying a Download Properly
The reliable sequence is: get the checksum from a source separate from the download itself — the project's signed release notes, a package index, a documentation site on a different host — then compute the digest of the file you received and compare. Where a signature over the checksum file is available, verify that first, then trust the checksums inside it.
For very large files, the practical constraint is that the whole file must be read to compute a digest, which is why this tool works with text rather than uploads. A file-based check belongs at the command line or in your operating system's built-in utility, both of which stream the file without loading it entirely into memory. Where this page helps is the comparison step afterwards, which is where the human error actually occurs.
Timing-Safe Comparison in Application Code
One point worth carrying into your own code: comparing secrets should not use ordinary string equality. Most implementations return as soon as they find a differing character, so the time taken depends on how many leading characters matched. Where the value being compared is a security token — an API signature, a session identifier, a password reset code — that timing difference can leak the correct value one character at a time to an attacker able to measure it precisely.
Constant-time comparison functions exist in every mainstream language's standard library for exactly this reason. That concern does not apply to verifying a published file checksum, where the expected value is public by design, but it very much applies to webhook signature verification, which is the most common place developers get it wrong.
Arb Digital's web development team builds deployment pipelines with integrity checks, reproducible builds, and rollback paths that are tested before you need them.
Web Development Services Talk to Arb DigitalCommon Mistakes to Avoid
- Checking only the first and last few characters. The middle of the string is exactly where a substituted value differs.
- Taking the checksum from the same page as the download. Anyone who can replace one can replace the other.
- Ignoring trailing newlines and line endings. They change the bytes, so they change the digest.
- Treating a matching MD5 as proof of authenticity. It proves the bytes match a published value, not that the value came from a trustworthy source.
- Using ordinary string equality on secret tokens in code. Use a constant-time comparison to avoid leaking information through timing.
Related Free Tools From Arb Digital
Compute a digest from scratch with the hash generator, check file integrity values with the CRC32 hash generator, compare two blocks of text line by line using the diff checker, decode a signed token with the JWT decoder, and translate binary payloads using Base64 encode and decode. More are in the free online tools hub.
Frequently Asked Questions
No. MD5 runs in JavaScript on this page and SHA-1 and SHA-256 use the browser's built-in Web Crypto interface. No network request is made.
By digest length. A 32-character hex value is MD5, 40 characters is SHA-1, and 64 characters is SHA-256, so the algorithm can be inferred from the value alone.
No. It proves the bytes match the published digest. If the digest came from the same place as the file, anyone who could replace one could replace both.
For detecting accidental corruption it remains serviceable, because random damage will not produce a colliding value. It is not adequate where an attacker chooses the content.
Usually because the bytes differ rather than the hash. Trailing newlines, Windows versus Unix line endings, and character encoding differences all change the result.
No. Hexadecimal digests are case-insensitive, and this tool normalises case before comparing, so an uppercase value matches its lowercase equivalent.
Compute the file digest with your operating system's built-in utility, then paste both values here to compare. This page hashes text rather than uploaded files.
Checksum verification detects changed bytes. It is not a substitute for a cryptographic signature when the source of a file needs to be proven.
