Developer Tools·4 min read

How Hashing Works: Checksums and File Integrity

Hashing fits in one sentence: feed bytes in, get a fixed-length fingerprint out, and identical input always yields an identical digest. The consequences take longer to appreciate. A checksum can prove a 4 GB download arrived intact, that two configs match byte for byte, or that a file changed when nobody expected it to. This guide covers the mechanics, a SHA-256 example you can reproduce yourself, how to check a file against a published checksum, which algorithms still deserve trust, and the small mistakes that make two digests disagree for no obvious reason.

Open the free Hash Generator All insights

The artifact that didn't match its checksum

Integrity checks in the wild.

A CI pipeline pulls a build artifact from storage, compares its SHA-256 digest against the value recorded at build time, and stops cold: the digests differ. No error was thrown during transfer, the file size looks right, and yet one byte somewhere isn't what it was. Without the comparison, that corrupted artifact would have shipped.

That's the everyday job of a hash: not secrecy, but evidence. Any change to the input, even a single flipped bit, produces a wildly different digest, so a matching fingerprint is strong proof that nothing moved.

How hashing works under the hood

A hash function consumes input of any length and emits output of one fixed length. Three properties make it useful. It's deterministic, so the same bytes always map to the same digest. It's one-way, so you can't reconstruct input from output. And it has the avalanche property, meaning a tiny input change rewrites the entire digest.

The Hash Generator computes MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-512 and CRC32 at once, and can switch every one of them to HMAC with a secret key. SHA-1 and the SHA-2 family run through the browser's Web Crypto API, while MD5, SHA-3 and CRC32 use small built-in implementations, since Web Crypto doesn't offer them. Nothing is uploaded, and because these algorithms are standardized, the digest you get here is identical to what OpenSSL, Python's hashlib, or sha256sum would report for the same bytes.

A SHA-256 example you can verify

Hash the exact string hello world, no capital letters and no trailing newline, and SHA-256 returns b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9. That's 64 hex characters encoding 256 bits. The same input through SHA-1 gives 2aae6c35c94fcfb415dbe95f408b9ce91ee846ed, 40 characters for 160 bits, and MD5 gives 5eb63bbbe01eeed093cb22bb8f5acdc3, 32 characters for 128 bits.

Reproduce it anywhere: click Try sample on the Text tab, which fills in hello world, or run printf 'hello world' piped into sha256sum on Linux. If your result differs, your input differs, and the usual suspect is a newline that echo appended without asking.

Verifying downloads with checksums

Projects that distribute binaries usually publish a digest next to each release, often in a SHA256SUMS file. After downloading, you compute the digest of your local copy and compare. A match means the bytes you hold are the bytes they published; a mismatch means corruption in transit, a broken mirror, or tampering.

In the Hash Generator, switch to the Files tab and drop the file, up to 200 MB. It's read in your browser and never uploaded. Then paste the published value into Compare with an expected hash. The matching algorithm turns green, so you don't have to know in advance whether the publisher used SHA-256 or SHA-512. If nothing matches, the tool tells you which algorithm the length points to, which confirms the file really differs rather than the algorithm being wrong. For text content, release notes or config payloads, the Text tab hashes as you type.

MD5, SHA-1 and SHA-256: which to trust

MD5 collisions, two different inputs producing one digest, have been practical to manufacture since 2004, and SHA-1 followed with a demonstrated collision in 2017. Once an attacker can craft two files sharing a fingerprint, the fingerprint stops proving anything against a motivated adversary.

That doesn't make them useless. Plenty of download pages and older systems still publish MD5 or SHA-1 values, and both still catch accidental corruption, which is why the generator includes them. It labels MD5 as for checksums only and marks SHA-1 as legacy. SHA-256 has no known practical collisions and remains the default for new checksums and signatures, so reach for it whenever you get to choose.

Hashing mistakes that waste an afternoon

When two digests refuse to match, it's almost always one of these:

A trailing newline. echo adds one and printf doesn't, so the two commands hash different byte sequences.
Line endings and encoding. Windows CRLF endings, or the same visible text in UTF-16 instead of UTF-8, are different bytes, and different bytes mean different digests.
Comparing only the first few characters of each digest by eye. Paste the full value into the compare box instead of squinting.
Assuming a hash can be decrypted. Digests are one-way by design; there is nothing to reverse.
Hashing passwords with a fast algorithm. Password storage belongs to salted, deliberately slow functions like bcrypt or Argon2, not to general-purpose digests.

Tips for dependable integrity checks

Record the algorithm alongside every digest you publish. A bare hex string forces the next person to work backward from its length, and if you ever publish SHA-512/256 or a truncated value, the length stops being a reliable clue.

Automate the comparison wherever the check matters. A script that diffs two strings never gets tired, while a human comparing 64 characters at 5 PM absolutely does. Default to SHA-256 unless a spec demands otherwise.

Hashing or encoding: picking the right tool

Base64 looks superficially similar to hash output but does the opposite job: it's a reversible encoding, not a fingerprint. If you need to pack binary data into text and get it back later, that's Base64 Decode and Encode.

And if you're staring at a JSON Web Token, its third segment is a signature built on hash-based cryptography, but the readable claims live in the first two parts. The JWT Decoder unpacks those directly.