Hash generator

What a hash function actually does

A cryptographic hash function takes an input of any size and produces a fixed-length string of bytes — a digest, or "hash". Feed it one letter or an entire novel and MD5 always returns 16 bytes, SHA-256 always returns 32. The same input always produces the same digest, and changing a single bit anywhere in the input changes roughly half the bits of the output, which is why two nearly identical files have completely unrelated hashes.

The crucial property is that the function only runs one way. Computing the hash of a file is fast; recovering the file from its hash is not merely slow but impossible in principle, because a fixed-length output cannot encode an unbounded input. A hash is a fingerprint, not an encrypted copy — there is nothing to decrypt.

What people actually use hashes for

• Verifying downloads: a project publishes the SHA-256 of a release, you hash the file you received, and matching digests mean the bytes arrived intact.
• Detecting change: version control, backup and deduplication systems compare hashes instead of whole files, because comparing 32 bytes is far cheaper than comparing gigabytes.
• Subresource Integrity: a web page pins the Base64 hash of a script it loads from a CDN, and the browser refuses to run the file if it does not match.
• Storing passwords — but with a purpose-built slow function, never a plain hash. See below.

Notice what these have in common: the hash is a compact stand-in for something larger, used to answer "is this the same thing I expected?" without transmitting or storing the thing itself.

MD5 and SHA-1 are broken — what that means in practice

A hash function is considered broken once someone can construct a collision: two different inputs producing the same digest. MD5 collisions have been computable on ordinary hardware since 2004, and in 2017 the SHAttered attack produced two different PDF files with an identical SHA-1 hash. Both algorithms are marked in this tool for that reason.

The practical consequence is narrower than "never use them". A collision means an attacker who controls both files can make a malicious one match a benign one's digest, so MD5 and SHA-1 can no longer prove that a file has not been tampered with by someone hostile. They are still perfectly serviceable for detecting accidental corruption — a truncated download, a flipped bit on a disk — and you will keep meeting them in legacy systems, ETag headers and older package manifests that are not going to be rewritten.

The rule of thumb: if the question is "did this get damaged in transit?", MD5 is fine. If the question is "did someone replace this on purpose?", use SHA-256 or better.

Never hash a password with these

MD5, SHA-1 and even SHA-256 are designed to be fast, and speed is exactly the wrong property for storing passwords. A modern GPU computes billions of SHA-256 hashes per second, so a stolen database of plain hashed passwords can be attacked at enormous scale — and because the same password always produces the same digest, precomputed tables make it cheaper still.

Password storage needs a deliberately slow, salted, memory-hard function: Argon2id, scrypt, or bcrypt. They add a unique random salt per password, so identical passwords do not share a digest, and they are tunably expensive, so each guess costs an attacker real time and memory. This tool is for checksums and fingerprints, not for password hashing.

Reading and comparing digests

The same digest can be written in more than one way. Lowercase hexadecimal is what the standard command-line tools print, and it is what you will usually be comparing against:

md5sum file.iso                  # Linux
sha256sum file.iso               # Linux
shasum -a 256 file.iso           # macOS
Get-FileHash file.iso -Algorithm SHA256   # PowerShell (prints uppercase)
certutil -hashfile file.iso SHA256        # Windows (prints uppercase)

Hex case carries no meaning — PowerShell and certutil print uppercase, the Unix tools print lowercase, and the two are the same value. The compare box in this tool ignores hex case for that reason. Base64 is a different matter: it is a denser encoding of the same bytes, used by Subresource Integrity and various APIs, and there case is significant, so it is compared exactly.

One last habit worth forming: never eyeball two long digests to decide whether they match. The human eye is very good at seeing what it expects, and the first and last few characters agreeing means nothing. Paste the expected value in and let the comparison be exact.