About Hash & Checksum Generator
Hash & Checksum Generator computes MD5, SHA-1, SHA-256, SHA-384, and SHA-512 digests for text you type or a file you select, printing the result as lowercase hexadecimal. It answers one question: are these two byte sequences identical under the algorithm the publisher used?
A hash is a one-way fingerprint, not encryption. There is no key and no inverse, so decrypting a digest is not a thing that can be done — an attacker guesses inputs and compares. The word "broken" needs the same care: MD5 and SHA-1 are broken for collision resistance, meaning two different files can be built to share one digest, but nobody can reconstruct your file from your digest.
How to use this developer tool
- Select the algorithm the publisher used. A digest means nothing except against the same algorithm.
- Type or paste text into the text pane, or use the file picker for a local file of up to 64 MB.
- Run the calculation and copy the hex string exactly, adding no surrounding whitespace.
- Compare against the reference in the Text Compare & Diff Checker rather than reading 128 hex characters by eye.
- Record the algorithm alongside the digest. A bare hex string with no algorithm is not a verifiable claim.
Worked example: one line of text, three different digests
A file containing the single line hello world, saved with no final newline, with a Unix newline, and with a Windows newline. Nothing a person would call the content changed.
hello world 11 bytes, no trailing newline
hello world + LF 12 bytes, Unix line ending
hello world + CRLF 13 bytes, Windows line endingb94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447
572a95fee9c0f320030789e4883707affe12482fbb1ea04b3ea8267c87a890fbThis is the most common reason a published checksum fails to match: a file committed to Git and checked out with core.autocrlf enabled has different bytes than the one the maintainer hashed. Hash the artifact that was distributed, not a copy extracted and re-saved.
Digest algorithms and where each one still belongs
This tool offers the first five rows. "Broken" always means collision resistance: an adversary can construct two inputs with one digest. No practical preimage attack exists against any of these, which is why an old algorithm can still catch accidental corruption.
| Algorithm | Digest size | Collision resistance | Use today |
|---|---|---|---|
| MD5 | 128 bits / 32 hex | Broken since 2004; chosen-prefix since 2009 | Corruption checks and cache keys only |
| SHA-1 | 160 bits / 40 hex | Broken in practice since 2017 | Legacy compatibility, never new designs |
| SHA-256 | 256 bits / 64 hex | No known weakness | The default for integrity and signatures |
| SHA-384 | 384 bits / 96 hex | No known weakness | Truncated SHA-512; common in TLS and SRI |
| SHA-512 | 512 bits / 128 hex | No known weakness | Often faster than SHA-256 on 64-bit CPUs |
| SHA-3, BLAKE2, BLAKE3 | typically 256 bits | No known weakness | Not offered here; use a CLI |
Troubleshooting
A file's digest does not match the value the project publishes.
Why it happens The bytes differ though the content looks identical. Line-ending conversion is the usual culprit, then an editor adding a final newline, then hashing extracted contents rather than the signed archive.
Fix Hash the downloaded artifact before touching it, and set core.autocrlf to input so checkouts do not rewrite endings.
The published checksum is shorter than the tool's output and contains + / and =.
Why it happens It is the same digest in Base64 rather than hex. npm integrity fields and Subresource Integrity attributes both use Base64 of the raw digest bytes.
Fix Convert with the Number Base & Radix Converter. The LF digest above is a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447 in hex and qUiQTy8PR5uPgZdpSzAYSw0u0cHNKh7A+4XSmaGSpEc= in Base64 — one value, two spellings.
Hashing the same text here gives a different result than a shell command.
Why it happens echo appends a newline, hashing 12 bytes where the text pane hashes exactly the 11 characters you typed, UTF-8 encoded.
Fix Use printf '%s' or echo -n when comparing against a browser digest, and check the byte count if they still disagree.
The checksum matched but the download was still tampered with.
Why it happens The checksum came from the same page, over the same connection, as the file. Anyone able to replace one could replace the other.
Fix Verify a signature instead when the threat is substitution, checking the publisher's key through an independent channel; the Certificate Parser shows what a chain asserts.
When this tool is the right choice
- Verifying a downloaded release archive against the checksum its publisher lists.
- Confirming a file survived a transfer, a backup restore, or a storage migration unchanged.
- Reproducing a known test vector while implementing or debugging a hashing routine.
- Producing a stable content key for a cache, a deduplication table, or an ETag.
When to use something else
- Storing user passwords. A raw SHA-256 is far too fast, which is what an attacker with your database wants; the htpasswd Entry Generator produces a bcrypt verifier instead.
- Making data unreadable but recoverable. That requires encryption; a hash has no key and no inverse.
- Proving who produced a file. A digest shows only that bytes match a published value; authorship needs a signature.
Privacy and data handling
The SHA family is computed by the browser's built-in WebCrypto implementation and MD5 by a library bundled into the page. File bytes are read locally through the File API: nothing is uploaded, and nothing survives closing the tab. One caveat applies to every hashing tool — a digest of a guessable value is itself a lookup key, so hashing a real password here does not protect it.
Related developer tools
Frequently asked questions
Can a hash be reversed?
Not by inverting it — the function discards information and has no key. But small input spaces can be searched exhaustively: a six-character password's SHA-256 falls in seconds on commodity hardware.
Is MD5 completely unusable now?
For anything an adversary can influence, yes, because collisions are cheap to construct. As a check against accidental corruption during a copy, or as a cache key over data you control, it is still adequate and fast.
Why does my file digest differ from the server's?
Any single byte counts: line endings, character encoding, a trailing newline, or timestamps embedded in an archive. Confirm both sides hashed the same artifact at the same stage with the same algorithm.
What about files larger than 64 MB?
The cap exists because a browser must hold the bytes in memory. Above it use shasum -a 256, or certutil -hashfile on Windows — both read the file in chunks rather than materializing it whole.
Is SHA-512 more secure than SHA-256?
It has more collision margin, but 256 bits is already far beyond any brute-force budget, so the practical difference is nil. Choose whichever the protocol specifies; on 64-bit CPUs SHA-512 is often faster.
Does the text pane include a trailing newline?
No. It hashes exactly the characters in the field, encoded as UTF-8. If a trailing newline is needed to match a file's digest, that difference comes from the file.