Checksum Calculator
Drop a file (or paste text) to compute its CRC32, MD5, SHA-1, and SHA-256 checksums, then paste the publisher’s expected value to verify a match - all in your browser.
- Free, no account
- No watermark
- No usage limit
About the Checksum Calculator
Most checksum tools make you pick the algorithm before you can check anything. Is the string the publisher gave you an MD5, a SHA-1, a SHA-256? Guess wrong from the dropdown and the tool cheerfully reports "no match," and now you can't tell whether the file is bad or you just chose the wrong option. Here you never have to make that choice. Drop your file, paste whatever checksum the publisher listed, and it runs your paste against CRC32, MD5, SHA-1, and SHA-256 at the same time, then turns the matching row green. You never have to know which one it was.
And it does the comparing for you, which sounds like nothing until you've tried to line up two 64-character hex strings by eye without going cross-eyed. All of it happens inside your browser. The file is read straight off your disk and hashed on your own machine, so a private installer or an unreleased build never gets handed to some stranger's server just so you can confirm it downloaded cleanly.
A checksum is a short string computed from a file's exact bytes. Change one bit anywhere, a half-finished download, a flipped byte off a failing drive, an installer someone swapped, and the whole string changes completely, top to bottom. So when a project posts the SHA-256 of its ISO, you push your copy through the same math and see whether the two strings agree. If they do, your copy is byte-for-byte what they shipped. If they don't, something happened between their server and your disk, and you shouldn't run it.
How to verify a downloaded file
- Drop your file on the box up top, or click Choose file. Any type works, an ISO, a ZIP, a firmware image, a PDF. It's read locally and never uploaded.
- Find the publisher's checksum. On the download page it's usually a line like
SHA256: a1b2c3...or a smallSHA256SUMSfile listing one hash per file. Read it over HTTPS on the official domain. A checksum served off a random mirror isn't worth much. - Paste it into the verify box. Copy the value for your exact file (version and architecture matter, a different build won't match) and drop it in. No need to figure out the algorithm first.
- Read the color. Green is a match and you're done. Red means re-download, because a truncated file is the usual culprit, then check again.
You don't have to name the algorithm (or format the paste perfectly)
This is the part I'm proud of. Publisher checksum lists are messy. Sometimes it's a bare hash, sometimes it's d41d8cd98f00b204e9800998ecf8427e installer.iso with the filename tacked on, sometimes it carries a leading 0x, sometimes it's shouted in uppercase, sometimes a BSD box wrote it as SHA256 (installer.iso) = a1b2c3... instead. Paste any of those and the tool sorts it out. Paste the entire SHA256SUMS file and it sorts that out too, every line of it. So you can copy sloppily, grab too much, not bother cleaning it up, and still get a clean verdict.
It also checks your paste against all four digests at once, so you never pick MD5 or SHA-256 from a menu and hope. If the publisher handed you a SHA-1 and you had no idea what it was, the SHA-1 row lights green anyway and tells you that's what it was. That kills the single most common way people get a false "no match," which is picking the wrong algorithm and then blaming the file.
Which of the four actually matters
Short version: if you get a choice, verify the SHA-256. It's the current standard for release verification and has no known practical weakness, so it's the one publishers reach for and the one least likely to ever bite you. The spec, if you want the primary source, is NIST FIPS 180-4.
The other three still show up in the wild, so the tool computes them too. CRC32 is a fast error check baked into ZIP and PNG, great for catching a garbled copy, useless against anyone deliberately faking a file. MD5 and SHA-1 are both broken for security, meaning a determined attacker can forge a collision, but random download corruption never will, so a matching MD5 still confirms your file arrived intact. Plenty of Linux mirrors list MD5 right next to SHA-256 for exactly that reason. The rule that keeps you out of trouble is boring and reliable: match whatever the publisher actually provided, and when they offer more than one, prefer the SHA-256.
Why a checksum "won't match" when you're sure it should
A checksum is computed over raw bytes, not over the text you see on screen. When you verify a file, the tool reads the exact bytes on your disk and there is no ambiguity. But the paste box has to turn characters into bytes first, and it does that as UTF-8. So if you open a text file, copy its contents, and paste them here expecting the hash to equal sha256sum file.txt, it often won't, and the file is completely fine.
What changed is invisible. Copy-paste can swap Windows line endings (\r\n) for Unix ones (\n), or quietly add or drop a trailing newline you can't see. Different bytes, different checksum, even though the two look identical on screen. So to verify a file, checksum the actual file by dropping it here, not its pasted-in text. Keep the paste box for strings you genuinely hold as strings, a token, a config value, a snippet you're matching against a known-good copy. When a mismatch blindsides you, suspect the encoding and a stray newline long before you suspect the tool.
Frequently asked questions
The publisher only gave an MD5. Is that safe to trust?
For confirming the download wasn't corrupted, yes, a matching MD5 does that job fine, because accidental damage can't produce a collision. MD5's weakness only shows up against someone deliberately crafting two files with the same hash, and even then they'd need to control the file you're pulling down. If you're just checking that an installer arrived in one piece off a reputable mirror, an MD5 match is genuine reassurance. If real trust rides on it, you want SHA-256 plus a signature.
Can two different files ever share a checksum?
With CRC32 and MD5, yes, and with SHA-1 it has been demonstrated, so someone can build two files with a matching hash on purpose. By accident, though, it basically never happens. Even a bad-luck corrupted download won't collide. For SHA-256 no practical collision has ever been found. So for spotting a botched download any of them works, and for defending against a deliberate swap you want SHA-256 pulled from a trusted source.
Can I paste the whole SHA256SUMS file instead of hunting for my line?
Yes, and it's the better way to use this. Every line gets compared, not just the first one, and the verdict tells you which line it came from. Drop your download into the box up top before you paste and the line carrying that exact filename is the one it rules on, so a release with your installer listed ninth out of eleven gets a straight answer. If the line naming your file disagrees, that's your answer and it stops there rather than going looking for some other line that happens to match, because a list that names your download and contradicts it is a damaged download.
What's the largest file I can check here?
There's no fixed cap. The real limit is your device's memory, since the file gets read in to be hashed, and on a normal laptop that's comfortably into multi-gigabyte territory, enough for most ISOs. A big file just takes a few seconds while your processor works through every byte. If you're routinely hashing very large files, or hundreds of them at once, a command-line tool like sha256sum streams from disk without holding the whole thing in memory and handles it more gracefully.
Does dropping a file here upload it?
No. It's read and hashed locally, and nothing is sent anywhere, which is also why the page keeps working after you disconnect from the internet. If you'd rather confirm that yourself, open your browser's network panel and drop a file, you'll watch zero requests fire. That's the whole reason to prefer a local tool for anything you'd rather not hand to a website.
Is a checksum the same as a GPG signature?
No, and the difference is the honest limit of any checksum. A checksum proves a file is the exact same bytes as some reference value. A signature goes further and proves who produced that reference, because it's vouched for by the publisher's private key. A checksum you fetched from a page an attacker controls proves nothing, they'd just post a fake file next to its matching fake hash. So a checksum catches corruption and casual tampering, and a signature is what catches someone who owns your download page.