How Hashing Works: SHA-256, MD5, and bcrypt Explained

A hash function takes any input, whether a single character or a 10 GB video file, and produces a fixed-length string of characters called a digest. Feed the same input twice and you get the same digest every time. Change one byte of the input and the digest changes completely. That two-sentence summary covers a concept that underlies password storage, file integrity checks, digital signatures, and blockchain ledgers. But it glosses over one critical detail: not all hash functions are safe for every job, and choosing the wrong one has caused real data breaches.

Last updated: July 2026

What a Hash Function Actually Does

A hash function is a deterministic, one-way mathematical operation. "One-way" means you cannot reverse it to recover the original input from the digest alone. This is different from encryption, which is designed to be reversible given the right key. A hash is a fingerprint, not a locked box.

Four properties define a useful cryptographic hash function:

• Determinism. The same input always produces the same output.
• Avalanche effect. A tiny change in input produces a wildly different digest. Changing one character in a 1,000-word document should flip roughly half the bits in the output.
• Pre-image resistance. Given a digest, it should be computationally infeasible to find any input that produces it.
• Collision resistance. It should be computationally infeasible to find two different inputs that produce the same digest.

When any of these properties breaks down, the algorithm is considered cryptographically broken, even if it still works fine for non-security uses.

MD5: Fast, Useful, Broken for Security

MD5 produces a 128-bit (32 hex character) digest. It was designed in 1991 and was standard for decades. Today it is broken for any security purpose because researchers have demonstrated practical collision attacks: two different files can be crafted to produce the exact same MD5 hash. This makes it unsuitable for verifying software downloads or storing passwords.

Where MD5 still makes sense:

• Detecting accidental file corruption (not adversarial tampering).
• Generating cache keys or deduplication identifiers in internal systems where no attacker can craft collisions.
• Checksums in legacy systems where you cannot change the algorithm without breaking compatibility.

If you need to quickly inspect a hash for debugging, the Hash Generator on EveryFreeTool lets you compute MD5, SHA-1, SHA-256, and SHA-512 in one place without installing anything.

SHA-256: The Current Workhorse

SHA-256 is part of the SHA-2 family, standardized by NIST. It produces a 256-bit (64 hex character) digest and has no known practical collision attacks as of 2026. It is the default choice for:

• Verifying file integrity (Git uses a variant to fingerprint every commit).
• Digital certificates and TLS handshakes.
• HMAC-based message authentication in APIs.
• Blockchain proof-of-work (Bitcoin uses double SHA-256).

SHA-256 is fast by design. A modern CPU can compute billions of SHA-256 hashes per second. That speed is an asset when you are hashing millions of log lines but a liability when you are hashing passwords, because an attacker can brute-force guesses at the same speed.

SHA-512 and SHA-3

SHA-512 doubles the digest length to 512 bits and is slightly faster than SHA-256 on 64-bit CPUs because of how the algorithm uses registers. SHA-3 (Keccak) is a completely different algorithm family standardized by NIST in 2015. It is not yet as widely deployed as SHA-2 but provides an independent backup if SHA-2 weaknesses are ever discovered. For most developers, SHA-256 remains the practical choice.

bcrypt: Slow by Design for Password Storage

bcrypt is not a general-purpose hash function. It is a password hashing function built specifically to be slow and memory-hard. It was published in 1999 and remains widely recommended today. Here is why it is different:

• Work factor (cost factor). bcrypt accepts a parameter, typically 10 to 14, that controls how many iterations the algorithm runs. Doubling the cost factor doubles the time to compute a hash. As hardware gets faster, you raise the cost factor.
• Built-in salting. bcrypt automatically generates a random salt and embeds it in the output string. This means two users with the same password get different hashes, defeating rainbow table attacks.
• Output format. A bcrypt hash looks like $2b$12$.... The 12 is the cost factor. The hash includes the salt and the digest in one self-contained string.

A cost factor of 12 typically takes 200 to 400 ms per hash on a modern server. That is imperceptibly slow for a user logging in once, but it makes brute-forcing a leaked database orders of magnitude harder than using SHA-256.

bcrypt vs. Argon2

Argon2 won the Password Hashing Competition in 2015 and is now the recommended choice in many modern security guidelines. It is memory-hard, meaning it requires a configurable amount of RAM in addition to CPU time. This makes it expensive to run on GPU clusters, which is exactly what attackers use. If you are starting a new project, prefer Argon2id. If you have a working bcrypt implementation, it remains acceptable and you do not need to migrate existing hashes immediately.

Salts and Rainbow Tables

A rainbow table is a precomputed lookup: for millions of common passwords, attackers store the hash alongside the plaintext. If you hash passwords with raw SHA-256 and an attacker gets your database, they can look up any common password in milliseconds.

A salt is a random value added to the password before hashing. Even if two users choose "password123," their salted hashes are completely different. The attacker must crack each hash individually, which eliminates the advantage of precomputed tables. bcrypt handles salting automatically. If you use SHA-256 for passwords (you should not, but if you do), you must add a random salt yourself and store it alongside the hash.

HMACs: Hashing With a Secret Key

An HMAC (Hash-based Message Authentication Code) combines a hash function with a secret key to produce a digest that proves both the message content and that the sender holds the key. It is the mechanism behind JWT signatures and most API authentication schemes.

When working with APIs that use HMAC-SHA256 signatures, it helps to test your request construction before writing production code. The API Request Tester on EveryFreeTool lets you fire requests and inspect responses directly in the browser, which speeds up debugging auth headers considerably. You can also use the JSON Formatter to verify the structure of a JWT payload before you hash it.

Common Mistakes Developers Make

1. Using MD5 or SHA-1 for passwords. These are fast hash functions. Attackers can test billions of guesses per second on consumer hardware. Use bcrypt, scrypt, or Argon2.
2. Confusing Base64 with encryption or hashing. Base64 is an encoding scheme, not a hash. It is entirely reversible with no key. It is useful for transporting binary data as text. The Base64 Encoder/Decoder can clarify the difference quickly when you are debugging an API response.
3. Not salting manually when using SHA-256 for passwords. If you insist on using SHA-256, you must add a unique random salt per user, store the salt, and never reuse salts across accounts.
4. Treating identical digests as proof of integrity in an adversarial context. If an attacker can modify both the file and its MD5 checksum, the checksum proves nothing. Always distribute checksums over a separate, trusted channel.
5. Using a low bcrypt cost factor. A cost factor of 4 (the minimum) takes microseconds. Set it to at least 10 in production, and benchmark on your actual hardware.

Quick Algorithm Reference

• MD5: 128-bit output, broken for security, fine for non-adversarial checksums.
• SHA-1: 160-bit output, collision attacks demonstrated, avoid for new systems.
• SHA-256: 256-bit output, no known practical attacks, general-purpose workhorse.
• SHA-512: 512-bit output, same security level as SHA-256 with larger margin, good for 64-bit systems.
• bcrypt: Variable output, built-in salt, intentionally slow, standard for password storage.
• Argon2id: Memory-hard, tunable, recommended for new password hashing implementations.

How to Verify a Hash in Practice

When a software project publishes a SHA-256 checksum next to a download link, the workflow is straightforward. Download the file, run your platform's checksum tool (shasum on macOS/Linux, Get-FileHash on Windows), and compare the output character by character to the published digest. If they match, the file arrived intact and was not replaced in transit. If they differ, do not open the file.

For quick experiments without opening a terminal, the Hash Generator on EveryFreeTool accepts pasted text and returns the digest instantly. It is not a substitute for verifying large file downloads, but it is useful for checking that your code produces the expected hash for a known test vector before you deploy it.