Checksums, hashes, and signatures: do not confuse their jobs

August 18, 2026 · NOFYI Editorial Team

A digest can help compare data, but it is only one building block in a larger integrity or authentication design. Checksums, cryptographic hashes, and digital signatures sound similar, and they are often lumped together under the word hash. In practice they answer different questions, fail in different ways, and are not interchangeable. Use the wrong one and you can end up with a check that looks reassuring but proves nothing about who sent the data or whether it was deliberately altered.

This guide explains what each mechanism actually guarantees, walks through a worked example you can try with the companion tool, and finishes with the limitations and mistakes that cause the most trouble in real projects.

What each tool answers

Before choosing a mechanism, state the question you are trying to answer. The three tools map to three different questions:

Checksum: Did this data probably survive copying or transmission without an accidental error?
Cryptographic hash: Is this exactly the same data I saw before, down to the last byte, and would even a tiny change be detectable?
Digital signature: Did the holder of a specific private key approve exactly this data, and has it changed since?

A checksum is designed for accidents: a flipped bit on a noisy link, a truncated download, a bad sector on a disk. A cryptographic hash is designed so that finding two different inputs with the same output is infeasible, and changing one bit of the input changes the output unpredictably. A digital signature adds identity on top of a hash: it binds a hash of the data to a key pair, so anyone with the public key can verify the signature but only the private-key holder could have creat

Cryptographic hashes: a fingerprint for exact data

A cryptographic hash function, such as SHA-256, takes an input of any length and produces a fixed-length output, often shown as a hexadecimal string. SHA-256 always produces 256 bits, usually written as 64 hex characters, whether the input is one word or a whole disk image. The function is deterministic: the same input always produces the same output. It is also one-way: given only the output, you cannot reconstruct the input. And it has the avalanche effect: changing a single character in the input produces a completely different-looking output, with no obvious relationship to the original.

Two more properties matter for security work. A good hash function is preimage resistant, meaning you cannot feasibly craft an input that hashes to a chosen output. It is also collision resistant, meaning you cannot feasibly find two different inputs that produce the same output. Those properties are what separate SHA-256 from a checksum. A checksum is easy to forge because its algorithm is simple; a cryptographic hash is designed so that forging a matching input is computationally infeasible.

That is why hashes are used to fingerprint files, to compare datasets, to build content-addressed storage, and to commit to data without revealing it. If you publish the SHA-256 hash of a release file, anyone can download the file from any mirror and confirm they received exactly the bytes you released, byte for byte.

But a hash by itself still does not prove who produced the data. If an attacker replaces both the file and the hash listed on a compromised download page, the victim’s check will pass. The hash only proves that the data matches the hash value you compared it against. That is why the source of the expected hash matters as much as the hash itself. An expected value fetched from the same compromised page as the file proves nothing. An expected value fetched over a separate trusted channel, from a signed release note, or from a package manager that verifies signatures,

Limitations

Every mechanism in this guide has limits worth stating plainly. A checksum cannot detect deliberate tampering. A cryptographic hash cannot prove who created the data, cannot tell you whether the original data was correct, and cannot recover data that was lost. A keyed hash cannot distinguish between holders of the same shared secret. A digital signature cannot prove that the signer understood or intended what they signed, cannot protect a private key that has been stolen, and cannot help if the verifier skips the check or trusts the wrong key.

There is also a freshness problem. A valid hash or signature proves that data has not changed since it was hashed or signed. It does not prove that the data is current. An attacker can replay an old signed message that is still valid. Systems that need freshness add timestamps, nonces, or version numbers and check them, rather than relying on the signature alone.

Finally, none of these mechanisms fixes a broken process. If the expected hash is copied by hand and mistyped, if the signing key lives on the same server as the files it signs, or if verification failures are logged but ignored, the cryptography is not the weak point. The workflow around it is.

Frequently asked questions

Is a hash the same as encryption?

No. Encryption is reversible with the right key; hashing is one-way by design. You encrypt data to keep it secret and decrypt it later. You hash data to produce a fixed-length fingerprint you can compare. A hash does not hide the data, and you cannot recover the original input from the hash alone.

Can two different files have the same SHA-256 hash?

In theory, yes, because there are more possible inputs than possible 256-bit outputs. In practice, finding such a collision for SHA-256 is considered infeasible with current knowledge and hardware. That is the property that makes SHA-256 suitable as a fingerprint. The same cannot be said for MD5 or SHA-1, which have practical collision attacks and should not be used for security purposes.

Should I use a checksum or a hash to verify a download?

Use a cryptographic hash such as SHA-256, and get the expected value from a trustworthy source. A checksum is fine for detecting accidental corruption on a trusted channel, but it will not stop someone who deliberately alters the file and recomputes the checksum. If the publisher only provides a checksum, treat it as an error check, not as proof of authenticity, and prefer a source that provides signed releases or a hash distributed separately.

Does a digital signature prove that a document is trustworthy?

It proves that the holder of a specific private key signed exactly that document and that the document has not changed since. It does not prove that the content is true, that the signer is who you think they are unless you trust the binding between the key and the identity, or that the key had not been compromised. Always check which key signed the document, where that key came from, and whether the signature system reports any expiry or revocation.

Use the related tool carefully

This guide is paired with a browser-only utility. The tool is a practical aid for small examples and inspection; it is not a substitute for application testing, a formal data pipeline, or professional review where the decision has higher consequences.

Related tools in this category

Sources

Choosing the right tool

Use this decision guide when you are unsure which mechanism fits:

Detecting accidental corruption on a trusted channel, such as a copy between your own systems: a checksum is usually enough and is the cheapest option.
Confirming exact bytes against a known good value, such as verifying a download or deduplicating files: use a cryptographic hash like SHA-256, and get the expected value from a trustworthy source.
Verifying a webhook or API request from a known partner who shares a secret with you: use HMAC with that shared secret.
Proving that a specific key holder approved data, especially when verifiers should not be able to forge messages: use a digital signature, and distribute the public key through a trustworthy channel.
Storing passwords: none of the above, used plainly. Password storage needs a purpose-built, slow, salted password-hashing design, as explained below.

If you are ever tempted to say we hash it, so it is secure, stop and ask which property you actually need. A hash alone does not authenticate, a checksum alone does not resist attackers, and a signature alone does not help if nobody checks which key signed it.

Common mistakes to avoid

Mistake 1: Treating a checksum as a security control. CRC32 and similar checksums are trivially forgeable. They catch accidents, not attackers. Do not use them to verify downloads from untrusted sources or to protect data in transit.

Mistake 2: Comparing a hash against a value from the same untrusted source. If the attacker controls both the file and the hash shown next to it, the check is theatre. Get the expected hash from a separate trusted channel, a signed release, or a package manager.

Mistake 3: Using a fast hash for password storage. SHA-256 is fast by design, which is exactly what makes it a poor password store. Attackers can try billions of candidate passwords per second against fast hashes. Password storage needs a slow, memory-hard, salted function designed for that purpose, such as Argon2, scrypt, or bcrypt, with parameters chosen for current hardware. Never store a plain MD5 or SHA-256 of a password, even with a salt, when a purpose-built password-hashing function is available.

Mistake 4: Confusing encoding with hashing. Base64 is an encoding, not a hash. It is reversible by design. Hashing is one-way. If you can decode it back to the original, it was not a hash.

Mistake 5: Using a broken or outdated hash for security. MD5 and SHA-1 have known collision attacks and should not be used for security-sensitive integrity or signature purposes. SHA-256 or a stronger member of the SHA-2 or SHA-3 families is the safer default for new work. A legacy checksum or hash that remains only for compatibility with an old format should be treated as an error check, not as proof of integrity.

Mistake 6: Signing without verifying the key. A signature is only as good as the trust in the public key. Pin or verify the key through a trustworthy channel, check expiry and revocation where the system supports it, and do not accept a self-asserted key from the same source as the signed data without an independent check.

Keyed hashes: proving a message came from someone with the key

A plain hash answers is this the same data? A keyed hash answers does the sender know a secret key? The standard construction is HMAC, which combines a secret key with the message and a hash function. Two parties who share the key can each compute the HMAC and compare. Someone without the key cannot produce a valid HMAC for a modified message, even though they can compute a plain hash of anything.

HMAC is widely used for API request signing and webhook verification. When a service sends your server a webhook, it often includes an HMAC signature computed with a shared secret. Your server recomputes the HMAC over the received payload and compares it with the header. If they match, the payload came from someone holding the secret and was not altered in transit. If they differ, reject the request.

Two implementation details matter. First, compare HMAC values in constant time so that the comparison itself does not leak information through timing. Most languages provide a safe comparison function for this; a plain string equality check is not ideal for secret values. Second, keep the key secret and rotate it when it may have leaked. A keyed hash is only as trustworthy as the handling of its key.

HMAC proves that the sender knows the shared secret. It does not prove which individual sent the message, because everyone who holds the shared key can produce a valid HMAC. When you need to distinguish between individual senders, or when the verifier should not be able to forge messages itself, you need digital signatures instead.

Digital signatures: proving who approved the data

A digital signature uses asymmetric cryptography: a private key that only the signer holds, and a public key that anyone can use to verify. Signing typically works like this. The signer computes a hash of the message, then transforms that hash with the private key to produce the signature. The verifier recomputes the hash of the received message, checks the signature against it using the public key, and accepts only if everything matches. If the message changed after signing, the hash will not match. If the signature was not created with the corresponding private key, verification fails.

Signatures are used for software releases, code signing, document signing, TLS certificates, and package distribution. When your operating system installs an update, it is typically checking a signature against a public key it already trusts, not just comparing a hash from the same download server. That separation matters: the signature is only meaningful if the public key itself comes from a trustworthy source. A signature that verifies against an attacker’s key proves that the attacker signed the file, which is not helpful unless you already know which key to trust.

Signatures also differ from HMAC in an important way. With HMAC, the verifier holds the same secret as the signer, so the verifier could forge a message too. With signatures, the verifier holds only the public key, which cannot create signatures. That is why signatures support non-repudiation in a way shared-secret schemes do not: the signer cannot plausibly claim that someone else forged the signature, because only the private-key holder could have made it, assuming the key was properly protected.

Good signature practice includes using a modern algorithm and key size, hashing the data before signing, protecting the private key with hardware or strict access controls where possible, and planning for key rotation and revocation. A signature made with a weak algorithm, a short key, or a leaked private key is not evidence of anything. Likewise, a signature that never expires and is never checked against a revocation list can remain dangerous long after the key should have been retired.

is worth much more.

Worked example: verifying a download with SHA-256

Suppose you download a file called report.pdf and the publisher lists its SHA-256 hash on their official release page. Here is the check:

Download the file and note the published hash from a channel you trust. Do not copy the hash from the same mirror that served the file if you can avoid it.
Compute the SHA-256 hash of the file you received. You can use the companion tool on this page for a small text example, or a command-line tool for a real file. On macOS or Linux, shasum -a 256 report.pdf prints the hash. On Windows, Get-FileHash report.pdf -Algorithm SHA256 in PowerShell does the same.
Compare the two hashes character by character. Do not eyeball the first few characters. A single differing character means the files differ, even if the sizes look identical.
If they match, you have strong evidence that the file you received is byte-identical to the one the publisher hashed. If they differ, do not use the file. Re-download it from a different source, and treat the mismatch as a real warning rather than a glitch to work around.

Try the idea with text first. Hash the sentence The quick brown fox jumps over the lazy dog and then hash the same sentence with the final period removed. The two hashes will look completely unrelated, even though the inputs differ by one character. That is the avalanche effect in action, and it is exactly why a hash comparison catches changes that a file size or a quick glance would miss.

One more practical point: hash the bytes, not your interpretation of them. A file with Windows line endings and the same file with Unix line endings are different byte sequences and will hash differently. A document that looks identical in two editors can hash differently because of invisible encoding, metadata, or whitespace differences. When a hash comparison fails, check whether the file was re-saved, converted, or re-encoded somewhere along the way before assuming an attack.

ed it.

Notice what is missing from that list. None of these tools encrypts your data. A hash or signature does not hide content. Anyone who can see the data can compute its checksum or hash. A signature proves approval; it does not keep the message secret.

Checksums: cheap, fast, and only for accidents

A checksum is a short value computed from a longer block of data by a simple rule. The sender computes it and sends it alongside the data; the receiver recomputes it and compares. If the values differ, something changed in transit. If they match, the data probably arrived intact.

Common checksums include CRC32, Adler-32, and the simple sums used in many file formats and network protocols. They are fast and easy to implement, and they catch the kinds of errors that happen by chance: a single flipped bit, a burst of noise, a dropped byte. That is their whole job, and they do it well.

What a checksum does not do is resist an attacker. Checksums are deliberately simple, which means an attacker who can modify the data can also recompute a matching checksum in milliseconds. If someone intercepts a file and changes both the file and its CRC32, the receiver sees a perfect match. A checksum therefore proves nothing about authenticity. It only guards against accidents on a channel you already trust.

Use a checksum when the threat is noise, not malice: verifying a file copied between two disks you control, checking a download over a connection you trust, or detecting corruption in a storage format. Do not rely on a checksum when the data crosses an untrusted network or comes from a source you cannot verify another way.