How to tell which hash algorithm a checksum uses

It arrives with no label. A line in a README, a value in a support ticket, a column in an exported spreadsheet, or a string next to a download with nothing above it but the word checksum. Before you can check anything against it you have to know which function produced it, because handing your file to the wrong algorithm yields a perfectly valid digest that will never match in a thousand years of trying.

The answer is usually written on the front. Every hash function here has a fixed output size and hexadecimal spends exactly two characters per byte, so counting characters gets you most of the distance in about four seconds. Several algorithms share a size, which is what the rest of this page is for.

The length table comes first. Then the four encodings and conventions that make counting misleading before you have started, then the three lengths that stay genuinely ambiguous and how to settle each one. The last section is about what the answer implies: recognizing a value as MD5 or SHA-1 is also a verdict on how far it can be trusted. For a single algorithm’s length on its own, how long a SHA-256 hash is answers it in a sentence.

The length tells you almost everything

Hash functions are named for their output size in bits. Divide that by four for the number of hexadecimal characters, by eight for bytes. A SHA-256 digest is 256 bits, 32 bytes, 64 characters — three ways of saying one thing — and the digest of abc looks like this in full: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad.

In practice you will meet eight of these. SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-512, CRC32, MD5 and SHA-1 account for essentially every checksum published next to a download, which is why those are the eight this site’s calculators cover. The rest are real but specialized, and they tend to announce themselves: BLAKE2b turns up on Arch Linux’s download page, Whirlpool turns up in documentation written in 2009.

Make sure you are counting hexadecimal

Counting only means something once you know you are looking at hex — sixteen symbols, 0 to 9 and a to f, and nothing else. Four things routinely break that assumption.

• It is Base64, not hex. Mixed upper and lower case, possibly a +, a / or a trailing =. 44 characters ending in one = is a 256-bit digest, in practice SHA-256; 88 characters ending in == is 512-bit. The real trap is 64 characters of Base64, which is a 384-bit digest with the same character count as a SHA-256 in hex and no relationship to it.
• It names itself and you skipped the prefix. A value in a web page beginning sha384- or sha256- is a subresource integrity attribute: the algorithm is in the prefix and the rest is Base64. Read the label, ignore the length.
• There are separators. Certificate and key fingerprints are conventionally printed as byte pairs joined by colons, and some tools group hex in fours. Strip the punctuation before counting — twenty colon-separated pairs is a 40-character SHA-1, not a 59-character mystery.
• It is not a digest at all. A UUID is 32 hexadecimal digits wearing four hyphens. A string starting $2b$ is a bcrypt password hash with its cost and salt built in. A 64-character hex string is just as likely to be an API key as a checksum.

Case never changes the value. E3B0C442 and e3b0c442 are the same number written two ways, so a comparison that fails on case alone is comparing strings rather than values — lowercase both sides before you judge anything by eye.

The three ambiguous lengths

For these, the length has taken you as far as it can. The digest itself will not help: the output of a good hash function is indistinguishable from random bytes, with no version marker, no header and no structure to read.

64 characters: SHA-256 or SHA3-256

Assume SHA-256. It is the default for download verification by an enormous margin, and publishers who use SHA-3 nearly always say so precisely because they know the length is ambiguous. But treat it as an assumption rather than a fact — if a 64-character value refuses to match and the file and the build are right, SHA3-256 is one of the few candidates left worth trying. The two are completely different constructions rather than versions of each other, which SHA-2 vs SHA-3 goes into. BLAKE2s and BLAKE3 are also 256-bit, and you will generally know if you are in a project that uses them.

128 characters: SHA-512 or SHA3-512

The same situation one size up, with a third realistic candidate: BLAKE2b’s default output is also 512 bits, and it is what Arch Linux publishes beside its SHA-256 under the name b2sums. Context settles this one more often than it settles the 64-character case, because 512-bit digests are published deliberately rather than by default — a file called SHA512SUMS is not being subtle about it.

8 characters: CRC32 or another check value

Eight hex characters is 32 bits, and 32-bit check values are everywhere: CRC32 inside ZIP and PNG, Adler-32 inside zlib, CRC32C in storage and networking hardware. Worse, CRC32 has presentation conventions of its own — byte order, and whether leading zeros are printed at all — so two correct implementations can show the same value differently, and an eight-character checksum that looks seven characters long is usually a dropped leading zero. Read an eight-character value as error detection rather than identification and you will not over-trust it; what CRC32 is actually for is the longer answer.

Settling it without guessing

Look outside the string. The filename is the strongest clue available: SHA256SUMS, sha1sum.txt, file.md5 and a CHECKSUM with the algorithm written inside all identify themselves. The layout of the line is next best. A value printed as MD5 (notes.txt) = … names its own algorithm in front of the digest, and once a line has identified itself that plainly, producing the matching 32-character MD5 for your own file is the next move. The GNU-style format instead puts the digest first and the filename after it: a plain two-column list with the digest first, two spaces, and sometimes an asterisk before the filename is the shasum family’s format, which reading a SHA256SUMS file takes apart line by line.

Or compute every candidate and look. If you have the file the digest is supposed to describe, you do not need to identify the algorithm at all. Produce all of them and see which one matches: a file is read once whether you ask for one digest or eight, so this costs nothing extra beyond the reading. Drop the file into the Files tool in Rocket Hash, open the row’s disclosure chevron to see every algorithm for it, and scan the column for your value. The row it sits in is your answer, and you have verified the file in the same pass.

When the mystery value is supposed to describe a string rather than a file — a line out of a config file, an API key, a token somebody pasted into a ticket — the same trick runs in a browser tab with nothing installed. Paste the text into the SHA-256 generator, then the same text into the MD5 generator, and compare each result with the value you are holding; the digests are computed on your own machine as you type, and nothing is uploaded. Those pages hash text only. For an ISO, a DMG or a folder, reading the bytes off the disk is the app’s job rather than a web page’s, which is why the route above goes through Files.

That second route also handles the case nobody likes admitting to: a value that is not a digest of the file at all, but of the archive it came in, of one member inside that archive, or of a build from a month ago. If none of the eight match, the algorithm was never the problem.

What the answer tells you about how far to trust it

Identifying the algorithm is also a verdict on the checksum. If it turns out to be MD5 or SHA-1, the value is still good at the job most checksums actually do and useless at the other one, and the distinction is worth having straight rather than inherited.

Collisions — two different inputs with the same digest — have been constructible for MD5 since 2004, and were demonstrated publicly for SHA-1 in 2017, when two different PDF files with an identical SHA-1 digest were published. That breaks one specific promise: nobody could have produced a second file with this digest. Somebody who authors both files can now arrange exactly that.

What has not broken is preimage resistance, or its near relation second preimage resistance. Nobody can work backwards from a digest to an input, and nobody can take an existing file they did not craft and build a different file with the same digest. So an MD5 you recorded yourself last year still proves your archive has not rotted, and an MD5 from a publisher you already trust still catches a corrupted download. What it cannot do is prove authorship to somebody who does not trust the publisher. Is MD5 still safe works through where that line falls.

Troubleshooting

The value is 64 characters and nothing I compute matches it

Then either it is SHA3-256 rather than SHA-256, or — far more often — it is a digest of something other than the file you have. Candidates: the compressed download rather than the image inside it, one file inside an archive, a different build of the same version, or a value somebody copied out of a previous release’s notes. Produce all eight digests for your file in Files first, because that rules the algorithm in or out in one pass and leaves you with a genuine mismatch to investigate instead. What to do when a checksum does not match ranks the rest of the causes.

The string has an odd number of characters

Then it is not a complete digest. Hexadecimal spends two characters per byte, so every digest length is even — an odd count means a character was dropped in a copy, or a line wrapped and lost something, or a leading zero was trimmed by a spreadsheet that decided the value was a number. Re-copy it from the source.

There are far more characters than any algorithm produces

You probably have more than one thing at once: two digests concatenated, or a whole manifest line with the filename still attached. Base64 is not the explanation — it spends four characters on three bytes where hexadecimal spends six, so the same digest is always shorter in Base64 than in hex and never longer. Several hundred characters of Base64 with BEGIN PGP SIGNATURE near it is not a checksum at all — that is a signature, which proves something quite different and is verified with different tools.

The value is shorter than any algorithm produces

Short prefixes are a real convention rather than an error: Git shows the first 7 to 12 characters of an object id, and plenty of build systems print a truncated digest so humans can compare two of them at a glance. They are fine for that and nothing else. A 12-character prefix has 48 bits behind it, which is few enough that accidental collisions stop being theoretical, so never accept a truncated digest as verification of a download.

Frequently asked questions

How do I know if a hash is MD5 or SHA-256?

Count the characters. An MD5 digest is 32 hexadecimal characters and a SHA-256 is 64, so the two are never mistakable once you have counted. If the value is 40 characters it is SHA-1, and if it is 128 it is SHA-512 or SHA3-512.

What hash algorithm is 64 characters long?

64 hexadecimal characters is a 256-bit digest, which in practice means SHA-256 — it is the default for download verification by a wide margin. SHA3-256, BLAKE2s and BLAKE3 are also 256-bit and share that length exactly, so a 64-character value that refuses to match is worth re-testing as SHA3-256. Note that 64 characters of Base64 rather than hex is a 384-bit digest instead.

Is a 40-character hash always SHA-1?

Almost always, but not by definition: RIPEMD-160 produces the same 160 bits and therefore the same 40 characters. Context decides it, and the context is usually Git, whose object ids are SHA-1 digests. RIPEMD-160 appears mostly in older PGP tooling and in some cryptocurrency address formats.

What hash is 44 characters long and ends with an equals sign?

That is a 256-bit digest written in Base64 rather than hexadecimal, and in practice it is SHA-256. Base64 packs three bytes into four characters, so 32 bytes becomes 44 characters with one = of padding at the end. A 512-bit digest in Base64 is 88 characters ending in ==.

Does it matter whether a checksum is uppercase or lowercase?

No. Hexadecimal digits have the same value in either case, so A3F0 and a3f0 are the same number and a tool that reports those as different is comparing text rather than comparing digests. Lowercase is the usual convention on Unix systems and uppercase turns up in Windows tooling and certificate fingerprints.

Can you tell which algorithm produced a hash just by looking at the value?

Only from its length. A good hash function produces output that is indistinguishable from random bytes — there is no version field, no header and no pattern to recognize, which is part of what makes it a good hash function. Everything beyond the character count has to come from context: the filename, the label beside it, the tool that printed it, or computing the candidates yourself and seeing which one matches.