How to Identify a Hash and Verify It

Quick Answer

A hash identifier is a reading of a digest you already have. It does not mint a new one. Paste one line, or up to 20. Each line is named by length: MD5, SHA-1, SHA-256, SHA-512, or CRC32. A length that matches none of those five is truncated or unknown. The page will not guess.

The page is a checksum verifier and a digest identifier. It will identify hash input by digest length, and it states SHA-1 versus SHA-256 when the character count is the difference. Strip a sha256sum filename before comparing.

You can also check the digest. Paste the text, or pick a local file. The browser hashes that input with the algorithm you pick, or with the one the length implies when only one length fits. The result is a match or a mismatch. Case does not count as a difference.

The paste stays on your device. Runs entirely on your device. Nothing is uploaded. There is no account. A file is read with the browser file reader, hashed in this tab, and then dropped. Use it when a download page, a terminal, or a ticket handed you a hash and you need to know what it is before you trust the file.

How does length identify a hash?

How does a tool tell these apart without hashing anything? It counts hex characters. MD5 is defined as 128 bits, which is 32 hex characters. SHA-1 is 160 bits, which is 40. SHA-256 is 256 bits, 64 hex characters. SHA-512 is 512 bits, 128 hex characters. CRC32 is 32 bits, written as 8 hex characters. The width is part of the algorithm. It is not a hint.

The page works by matching that width and nothing else. It does not look at the letters and decide the value "looks like" SHA-256. Every full digest looks like random hex. For example, the SHA-256 of the word hello is 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. Count the characters. There are 64. That is the whole identification.

The same word under SHA-1 is aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d. That is 40 characters. Under MD5 it is 5d41402abc4b2a76b9719d911017c592, 32 characters. Under CRC32 it is 3610a686, 8 characters. Same input, four widths, four names.

Why is a SHA-1 length not SHA-256?

Because 40 is not 64. A SHA-1 digest is shorter. Treating a SHA-1 digest as SHA-256 because both look like hex is the mistake that wastes the most time. The checker you opened produces 64 characters. Your paste has 40. They cannot match. The file is not corrupt. The algorithm is different.

This page says that in the result line: a SHA-1 length is not SHA-256. It refuses to compute a SHA-256 and then call the file bad. For example, paste aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d and choose SHA-256. The line names the length. It does not print a mismatch.

SHA-1 is also a weaker function. Collisions are practical, so new signatures should use SHA-256. That is a reason to care which name you were given. It is not a reason to stretch a 40 character string into a 64 character one.

What does a sha256sum line look like?

Reading a sha256sum line copied from a terminal is a normal way this digest arrives. GNU sha256sum prints two shapes. Text mode is the hex, two spaces, then the filename. Binary mode is the hex, one space, an asterisk, then the filename. For example:

2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 hello.txt

The filename is not part of the digest. Pasting a sha256sum line with the filename still attached used to make the whole line look like nonsense. This page strips that trailing name when the line has that shape, then it tells you a trailing filename was stripped. Checking a download checksum printed next to a file works the same way: keep the hex, drop the label.

A single space is a different string. 3610a686 hello.txt is not the sha256sum shape, so it is not treated as hex. Windows certutil wraps the digest in a sentence. Copy the hex on its own in that case. A sha256: prefix is also left alone, so you can see that the line is not bare hex.

How do I verify a file without uploading it?

Pick the file. The browser reads the bytes with a file reader and hashes them here. The bytes stay on this device. Nothing is sent. There is no form and no server. Files over 32 MB are refused so the tab does not lock up. That refusal happens before the read finishes the hash, and it is still local.

The algorithm is the one you pick, or the one inferred when the digest matches exactly one length. Infer is the default. If you paste a 64 character digest and the word hello, the page hashes hello as SHA-256 and compares. Confirming a pasted string matches a digest you were given is that comparison.

Text and files are not the same input. Text is hashed as UTF-8. A file is hashed as the raw bytes. Hashing pasted text when the checksum was of a file fails when the file has a newline you did not paste. For example, hello with no newline has SHA-256 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. hello followed by a line feed is a different digest. Use the file control for a file checksum.

While a file is selected, the text box is ignored. Clear the file if you meant to hash the text. The page says which source it used.

Which mistakes look like a corrupt file?

Three mistakes show up as a mismatch when the bytes were fine. Each one is named in the result line when it applies, and stays out of the line when it does not.

What is the difference between this page and a hash generator?

A generator's job is to create a digest. This page's job is to read one. Telling an MD5 digest from a SHA-256 digest by length is the first step. Verifying it is the second. The SHA-256 generator and the MD5 generator already compare a digest you paste against the one they just made. They do that for one algorithm, the one written on the page.

Those generators are the alternatives when the algorithm is already known. Use a generator when you do not have a digest yet. Use this page when the digest arrived first and the algorithm is the question. The SHA-1 generator is the right next stop when you have decided the file really should be hashed as SHA-1. CRC32 lives next to them for checksums that are not security checks.

This page will not crack a hash, build an HMAC, or upload the bytes. Those are different tools, and two of them do not belong in a browser tab at all. Cracking is search. HMAC needs a secret. Upload means the bytes left the device. None of that happens here.

Where do I go next?

Start here when the digest already exists. Move to a generator when you need a fresh one. Both sit in Developer Utilities. The generators are neighbors, not replacements: they will not tell you that a 40 character string was SHA-1 unless you already opened the SHA-1 page. This page will not mint a digest as its main job.