Hashing text is not hashing a file
Sumit Jha · Updated 2026-11-06
MD5, SHA-256, and the rest digest a sequence of bytes. Pasting text hashes the characters in the box, usually UTF-8, with whatever newline the box kept. Hashing a file hashes every byte on disk, including a UTF-8 BOM or CRLF line endings. Matching a published checksum means hashing the file, with the algorithm the publisher named.
Newlines and encodings change the digest
SHA-256("hello") is not SHA-256("hello\n"). Editors add a trailing newline. Git on Windows may check out CRLF while the published digest was computed on LF. A BOM at the start of a “plain text” file is three extra bytes. None of this is a broken hash function.
The text hasher is the right tool when the input is a string you can see: a token, a short fixture, a known answer from a spec. The file hasher is the right tool when the input is a download. It reads the file in the browser and does not upload it.
Length is not identification
A 32-character hex string is 16 bytes. MD5 is that long, and so are other 128-bit values. A 64-character hex string is consistent with SHA-256. The identifier lists candidates. It does not prove which function produced the digest, and it cannot recover the input. Hashes are one-way. bcrypt is a different construction with a salt and a cost, not a longer SHA.
MD5 and SHA-1 are fine for spotting accidental corruption of a download when the publisher still publishes them. They are not fine for passwords or for signatures. Prefer SHA-256 or SHA-512 when you choose the algorithm.
Make the bytes match the published digest
Hash the characters hello with SHA-256 in the text tool and keep the hex. Hash hello plus a newline. The digest changes. If a README shows a checksum for a snippet, look at whether the snippet includes the final newline. Editors add one on save. That single byte is the usual reason two “identical” strings disagree.
For a download, ignore the text box. Open the file in the file hasher and select the algorithm printed next to the checksum, not the one you prefer. A 64-character hex string is the right length for SHA-256. MD5 is 32 hex characters. If the site publishes both, either match is fine for an integrity check, and SHA-256 is the one to keep. The identifier can suggest those lengths. It cannot tell you the file is authentic if the checksum and the file came from the same untrusted page.
CRLF versus LF matters for text you checked out of git and then hashed. Hash the blob the publisher hashed, or convert line endings first and say that you did. A BOM is bytes EF BB BF at the start of otherwise ASCII text. None of these are collisions. A collision is two different inputs with the same digest, which you will not produce by accident with SHA-256. bcrypt is still the wrong comparison: it is a password hash with a salt and a cost, and it will not equal a SHA-256 of the same password.
If you publish a checksum, publish the algorithm in the same sentence as the hex. “The hash is …” with no name forces people into the identifier, which only lists lengths. SHA-256 and SHA-512/256 are different functions that both can appear as 64 hex characters. Length will not separate them. For a file, say which tool should be used: the file hasher, on the bytes as downloaded, before unzipping, unless the publisher hashed the unzipped tree and said so.
FAQ
Why doesn’t the text hash match the file hash?
The file has different bytes: line endings, a missing newline, or a BOM. Hash the file if the checksum was published for the file.
Can I reverse SHA-256?
No. You can only recompute it from a candidate input and compare.
Related tools
- File Hash CalculatorDrag a file in and compute MD5, SHA-1, SHA-256, SHA-512, Blake3 checksums.
- Hash IdentifierDetect the type of a hash (MD5, SHA-1, SHA-256, bcrypt, Argon2, UUID, etc.) by pattern.
Limitation: this note describes the DevTooKit tool and the general rule behind it. Production libraries, clocks, and schedulers can differ. Check those docs before you ship.