Hashing is one of those concepts that quietly powers a huge amount of modern computing — password storage, file-integrity checks, digital signatures, blockchains, and the deduplication that keeps your cloud storage small. Yet it is often confused with encryption, and the difference matters. This guide explains what a hash function actually does, why the once-ubiquitous MD5 is now considered broken, why SHA-256 became the default, and when to reach for each.
What is a hash function?
A hash function takes an input of any size — a word, a password, a multi-gigabyte file — and produces a fixed-length string of characters called a hash, digest, or checksum. SHA-256, for example, always outputs 256 bits (64 hexadecimal characters) no matter whether you feed it one letter or an entire movie.
The key idea is that the same input always produces the same output, but even a tiny change to the input produces a completely different hash. Hashing the word "hello" gives one digest; hashing "Hello" with a capital H gives a totally unrelated one. This makes a hash a kind of compact fingerprint for data.
What makes a hash function "good"?
A cryptographic hash function is judged on a few properties. It must be deterministic, so the same input always yields the same digest. It must be fast to compute for general use, yet practically impossible to reverse — given a digest, you should not be able to work backward to the original input. It should exhibit the avalanche effect, where flipping a single bit of input changes about half the output bits. And it must be collision-resistant: it should be infeasible to find two different inputs that produce the same hash.
When a hash function fails the last property — when attackers can deliberately manufacture collisions — it is considered broken for security purposes. That is exactly what happened to MD5.
MD5: fast, ubiquitous, and broken
MD5 produces a 128-bit (32-hex-character) digest and was the workhorse hash of the 1990s and 2000s. It is still everywhere: in legacy systems, as a quick checksum, and in plenty of tutorials. The problem is that researchers demonstrated practical collision attacks against MD5 years ago — it is now possible to create two different files with the same MD5 hash on a laptop in seconds.
That means MD5 must never be used where security depends on uniqueness: digital signatures, certificate validation, or password storage. It is acceptable only for non-adversarial uses such as a basic checksum to detect accidental file corruption, where nobody is actively trying to forge a match.
SHA-256: the modern standard
SHA-256 is part of the SHA-2 family designed by the NSA and published by NIST. It produces a 256-bit digest and, as of 2026, has no known practical collision attacks. It underpins TLS certificates, software-signing, Bitcoin, and countless integrity checks.
For almost any new project that needs a general-purpose cryptographic hash, SHA-256 (or its larger sibling SHA-512) is the safe default. The SHA-3 family exists as a structurally different backup standard, but SHA-256 remains the everyday workhorse and is supported natively in virtually every language and browser.
Hashing is not encryption
This is the most common confusion. Encryption is a two-way process: you scramble data with a key, and anyone with the right key can unscramble it back to the original. Hashing is one-way by design — there is no key and no way to "un-hash" a digest back into its input.
That one-way property is the whole point. You hash a password so that even if your database leaks, attackers do not get the actual passwords. You encrypt a message so the intended recipient can read it. If you ever need to recover the original data, you need encryption, not hashing.
Where hashing is used
File integrity is the classic case: a download page lists a SHA-256 checksum, you hash the file you received, and if the digests match you know the file arrived intact and untampered. Digital signatures hash a document and then sign the hash, which is far faster than signing the whole file. Version-control systems and cloud storage use hashes to deduplicate identical content and to detect changes. And password systems store a hash of each password rather than the password itself.
A warning about hashing passwords
It is tempting to store user passwords as a plain SHA-256 hash, but that is a mistake. General-purpose hashes like SHA-256 are designed to be fast, which is exactly what you do not want for passwords — an attacker with a leaked database can try billions of guesses per second.
For passwords, use a slow, salted password-hashing function built for the job: bcrypt, scrypt, or Argon2. These add a unique random salt per password (so identical passwords do not share a hash) and are deliberately expensive to compute, which cripples brute-force attacks. Use SHA-256 for integrity and signatures; use bcrypt or Argon2 for passwords.
How to generate a hash
You can compute a hash in seconds with the free hash generator on ToolboxHub. Paste or type your input, choose an algorithm such as MD5, SHA-1, or SHA-256, and the digest is produced instantly in your browser — nothing is uploaded to a server. It is handy for verifying a download checksum, comparing two files, or just seeing the avalanche effect in action by changing one character and watching the entire hash change.
The short version
A hash is a one-way, fixed-length fingerprint of data. MD5 is fast but broken — use it only for non-security checksums. SHA-256 is the modern default for integrity and signatures. Hashing is not encryption: it cannot be reversed. And never store passwords with a plain fast hash — reach for bcrypt, scrypt, or Argon2 instead.