MD5, SHA-256, and bcrypt: Hash Algorithms Explained Without a Computer Science Degree
Learn what hash algorithms do, why MD5 is no longer safe for passwords, when SHA-256 is the right choice, and how to generate hashes instantly online.
What is a hash algorithm and what does it actually do
A hash algorithm takes any input — a word, a file, a password, an entire database record — and produces a fixed-length string of characters called a hash or digest. The output length is always the same regardless of input size: MD5 always produces 32 hexadecimal characters, SHA-256 always produces 64. The key property that makes hashing useful is that it is a one-way function: you can compute the hash of any input instantly, but you cannot reverse the hash to recover the original input through any mathematical shortcut. A second critical property is that even a tiny change to the input — one character, one byte, one pixel — produces a completely different hash output. This is called the avalanche effect, and it is what makes hashes useful for detecting changes. Hashing a 10-gigabyte file and comparing the result to a known-good hash tells you with certainty whether the file has been modified or corrupted without having to compare every byte yourself.
MD5 and SHA-1: why these are no longer safe for passwords
MD5 was designed in 1991 and SHA-1 in 1995. Both were once considered secure, but both are now cryptographically broken for security-critical uses. The specific problem is collision resistance: researchers have demonstrated that it is possible to construct two different inputs that produce the same MD5 or SHA-1 hash. For password storage, the bigger practical problem is rainbow tables — precomputed databases of common passwords and their MD5 or SHA-1 hashes that allow attackers to look up the original password from a stolen hash in seconds. Despite this, MD5 and SHA-1 remain useful for non-security purposes such as file integrity checks, where the goal is detecting accidental corruption rather than preventing deliberate attacks. If you download a software package and the provider publishes its MD5 or SHA-1 checksum, computing the hash of your downloaded file and comparing it to the published value still tells you reliably whether the download completed without corruption.
SHA-256 and the SHA-2 family: the current standard for integrity and digital signatures
SHA-256 is part of the SHA-2 family published by NIST and is the current standard for most cryptographic applications where a general-purpose hash is needed. It is used in TLS certificates, code signing, Bitcoin mining, JWT signatures, and file integrity verification. SHA-256 has no known practical collision vulnerabilities and produces a 256-bit output that is computationally infeasible to reverse. When you see a file download page list a SHA-256 checksum alongside the download link, running the downloaded file through a SHA-256 hash tool and comparing the result to the published checksum is a reliable way to verify both integrity and authenticity — that the file was not modified in transit and matches exactly what the publisher signed. SHA-512, another SHA-2 variant, produces a longer 512-bit output and is sometimes preferred for high-security applications, though SHA-256 is sufficient for the vast majority of use cases.
bcrypt and password-specific hashing: why application passwords are different
For storing user passwords in a database, MD5, SHA-256, and other general-purpose hashes are all wrong choices — even SHA-256. The reason is speed: these algorithms are designed to be fast, which means an attacker with a GPU can test billions of password guesses per second against a stolen hash database. bcrypt, scrypt, and Argon2 are purpose-built password hashing algorithms that are intentionally slow and configurable — you set a cost factor that makes the hash computation take a fixed amount of time, such as 200 milliseconds. This cost scales with hardware improvements: as computers get faster, you raise the cost factor to keep hashing slow. The result is that a modern GPU that can test ten billion SHA-256 hashes per second can only test a few hundred bcrypt hashes per second at a reasonable cost factor. For application developers storing user passwords, the rule is simple: always use bcrypt, scrypt, or Argon2 — never MD5, SHA-1, or SHA-256 directly.
A practical workflow is to keep the original payload or query nearby, format the data once, and then compare the cleaned version against the source so you can spot missing fields, unexpected wrappers, or type changes before they become bugs. When a tool produces output you plan to reuse in code, paste it into the actual place it will live, such as a model class, test fixture, or README snippet, and verify that the structure still makes sense after one more read-through. The goal is not just prettier output, but fewer mistakes when the data moves from a scratchpad into a real project.
Before you rely on any generated output, test one realistic example and one messy edge case. That habit catches the problems that only show up in production, such as null fields, nested arrays, unexpected text encoding, or inconsistent naming conventions. Good developer tools reduce friction, but the review step still belongs to you.
Frequently asked questions