You download a software installer. Beside the download link, the developer's page lists a 64-character string: 3b4d6f9a1c8e2d5f.... You run the file through a hash tool and compare what it produces to that string. They match exactly. The file arrived unaltered.
That string is a hash. The hash generator at ToolCenterHub computes hashes from any text in the browser, with no data sent to a server. This guide covers what hash functions do at the technical level, why MD5 is broken for security applications but still valid for file checksums, how the avalanche effect works in practice, and how password hashing differs from file verification.
What a Hash Function Does
A hash function takes an input of any size and produces a fixed-length output. Feed it one word or a 500-page document: the output is always the same length. For SHA-256, that output is always 64 hexadecimal characters (256 bits). For MD5, it is always 32 characters (128 bits).
Three core properties define a functioning hash:
Deterministic: The same input always produces the same output. Hash the string hello with SHA-256 today and again next year: you get the same 64-character result.
Fixed output length: Input size does not change output size. The hash of a single letter and the hash of a 10GB file are both 64 characters in SHA-256.
One-way: Given the hash, you cannot recover the input. This is a mathematical property, not a computing power limitation. No known algorithm reverses a properly designed hash function.
To see this in practice, hashing hello with SHA-256 produces:
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
Hashing Hello (capital H) produces:
185f8db32921bd46d35fa3b8b61b5c6752d6f345af7b4fc1e9c31cc58e73e9e0
Completely different outputs from a single character change. That property is the avalanche effect, covered below.
The Three Security Properties That Matter
Hashes used in security contexts require three additional properties beyond basic determinism:
Preimage resistance: Given a hash, it is computationally infeasible to find any input that produces it. This is what protects stolen hash databases: an attacker cannot work backwards from a stored hash to the original password.
Second preimage resistance: Given an input and its hash, it is computationally infeasible to find a different input that produces the same hash. This prevents an attacker from substituting a malicious file that happens to produce a matching checksum.
Collision resistance: It is computationally infeasible to find any two distinct inputs that produce the same hash. This is the property that MD5 and SHA-1 have both lost.
A function that passes all three is considered cryptographically secure for most purposes. SHA-256 passes all three. MD5 fails collision resistance. SHA-1, which was broken by Google's SHAttered attack in 2017, also fails collision resistance.
How the Avalanche Effect Works
Change one character in an input and the entire hash changes. This is called the avalanche effect and it is a deliberate design property, not a side effect.
Hashing password with SHA-256:
5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8
Hashing Password (capital P):
e7cf3ef4f17c3999a94f2c6f612e8a888e5b1026878e4e19398b23bd38ec221a
Not one character overlaps between two 64-character strings that differ by a single bit. On average, approximately 50 percent of output bits change when a single input bit changes. This property means that an attacker examining a database of hashes cannot determine anything about how similar the underlying inputs were. Two hashes that look completely different might correspond to passwords differing by one character, and the attacker has no way to tell.
This is what makes hash functions resistant to differential cryptanalysis: feeding slightly modified inputs and watching how the output changes yields no useful information about the hash function's internal state.
MD5, SHA-1, SHA-256, and SHA-512 Compared
| Algorithm | Output Size | Hex Characters | Current Status |
|---|---|---|---|
| MD5 | 128 bits | 32 chars | Broken — collisions practical since 2004 |
| SHA-1 | 160 bits | 40 chars | Broken — SHAttered collision attack, 2017 |
| SHA-256 | 256 bits | 64 chars | Secure — current standard |
| SHA-512 | 512 bits | 128 chars | Secure — faster on 64-bit processors |
SHA-256 and SHA-512 are both part of the SHA-2 family, designed by the NSA and standardized by NIST. SHA-3, based on the Keccak algorithm, was approved by NIST in 2012 as an alternative family. SHA-3 is not faster than SHA-2 and does not replace it; it exists as a backup family in case a weakness is found in SHA-2's structure. SHA-256 remains the dominant deployed standard.
The hash generator in the developer tools section supports MD5, SHA-1, SHA-256, and SHA-512. For any security-sensitive use, select SHA-256 or SHA-512. The MD5 and SHA-1 options exist for compatibility with legacy systems that still require them for non-security purposes.
Why Is MD5 Broken?
MD5 was broken in 2004 by researcher Wang Xiaoyun, who published the first practical collision attack: a procedure for engineering two different inputs that produce the same MD5 hash. Before this work, finding a collision required testing an astronomically large number of inputs. The attack reduced this to hours on a desktop machine at the time of publication, and to seconds by 2010.
The real-world impact arrived in 2008 when security researchers demonstrated a forged SSL certificate using MD5 collisions. They created two different certificate signing requests that produced the same MD5 hash, then obtained a legitimate signature on one from a real certificate authority. The resulting certificate could be used to impersonate any website while appearing valid in browsers that trusted the CA. The attack was presented publicly at the Chaos Communication Congress in December 2008.
This is what "broken" means in cryptography: not just theoretically possible, but practically executable with available hardware.
What this means for actual use decisions:
Where the break matters: Digital signatures, TLS certificate validation, code signing, document authentication. Any context where an attacker can craft one of the two inputs being compared.
Where the break does not matter: Verifying that a downloaded file matches a checksum published on the developer's website. In this scenario, an attacker would need to produce a malicious file that executes something harmful, that also produces the same MD5 hash as the legitimate file, and also replace the checksum on the publisher's website. If the website is compromised enough to replace the listed checksum, the attacker would simply replace the download link entirely. For accidental corruption detection in transit, MD5 checksums still work.
How Hashing Is Used for Passwords
When you log into a website, the server does not store your password. It stores a hash of it. When you log in, the server hashes your submitted password and compares the result to the stored hash. A match grants access. The original password is never stored anywhere.
This matters when a database is stolen. If the database contains properly hashed passwords rather than plain text, an attacker cannot immediately read any password. They must crack each hash individually.
The choice of hash function matters enormously. SHA-256 produces a hash in microseconds. On a modern GPU, an attacker can test billions of SHA-256 guesses per second. A 6-character lowercase password takes under a second to crack against a SHA-256 hash. An 8-character mixed-case password takes minutes.
Password-specific hash functions address this by being intentionally slow. bcrypt runs an internal hash function 2^N times, where N is the work factor. At work factor 12 (a common setting), a single bcrypt hash takes approximately 300 milliseconds to compute. Argon2 (the winner of the Password Hashing Competition, 2015) adds memory hardness: it requires a configurable amount of RAM to compute, which neutralizes GPU attacks because GPUs have limited per-thread memory. NIST SP 800-63B (2017) explicitly recommends against storing passwords using unsalted or fast hashes, endorsing bcrypt, scrypt, and PBKDF2 for password storage.
The password generator generates passwords with the length and character complexity that makes brute-force expensive regardless of which hash function protects them on the server. The guide to creating strong passwords covers what length and character diversity actually shifts the cost of cracking.
What Is a Salt and Why Does It Prevent Lookup Attacks?
A rainbow table is a precomputed database mapping common passwords to their hashes. If a database stores unsalted SHA-256 hashes, an attacker who steals it can look up each hash in a rainbow table and recover the original password instantly for any common value. Tables for billions of common passwords are publicly available and downloadable.
A salt defeats this entirely. Before hashing, a random value (the salt) is concatenated with the password. Each user gets a different salt. Two users with the same password produce completely different hashes.
| Input | Hash Type | Output (abbreviated) |
|---|---|---|
hunter2 (no salt) | SHA-256 | f52fbd32b2b3b294... (same every time) |
hunter2 + salt xK9p2qLm | SHA-256 | a47f3d1b9c2e8f54... (unique to this user) |
hunter2 + salt mR7j5vNq | SHA-256 | b83c5a2d4f1e3a91... (different again) |
The salt is stored in plain text next to the hash. It does not need to be secret: its job is not to hide anything, but to make each hash unique so precomputed tables cannot be applied. With salts in place, an attacker who steals a database must crack each password individually, with no economies of scale.
The passphrase password generator guide explains why passphrases (multiple random words) outperform shorter random passwords against cracking attacks, which matters for what is actually stored in salted hash form. The guide comparing password managers and password generators covers how stored credentials relate to the authentication systems that hash them.
File Checksums vs. Password Hashing: Different Threat Models
These are two completely different applications of hashing with different security requirements.
File checksums exist to detect accidental corruption. A publisher hashes a file, posts the hash publicly, and you verify your download by hashing it yourself. MD5 is acceptable here because the threat is data corruption in transit, not an active attacker. An attacker who wanted to substitute a malicious file would need to produce a file that both (1) executes malware and (2) produces the same MD5 hash as the legitimate installer. While this is technically feasible with a collision attack, it requires controlling the published hash as well, at which point a simpler attack (just replacing the download link) would be more effective. For corruption detection, MD5 works.
Password storage protects against intentional attack after a breach. An attacker who steals a hash database is specifically trying to recover passwords. Speed is the threat: MD5 hashes at hundreds of millions per second per GPU. Use bcrypt or Argon2.
HMAC: Hashing With a Secret Key
HMAC (Hash-based Message Authentication Code) extends a standard hash by adding a shared secret key. A plain hash verifies content integrity: anyone can hash any message and produce a valid hash. HMAC verifies both content and sender: only someone who knows the key can produce a valid HMAC for a given message.
The construction is: HMAC(K, M) = H((K XOR opad) || H((K XOR ipad) || M)) where H is a hash function like SHA-256. In practice, you do not implement this manually. Libraries expose it as HMAC-SHA256(key, message).
HMAC-SHA256 appears in API authentication (AWS request signing, GitHub webhook verification), JWT token validation, and TLS record integrity. Any system that needs to verify that a message came from a trusted party and was not modified in transit uses HMAC rather than a plain hash.
For generating and comparing hashes from text inputs directly in the browser, the hash generator handles MD5, SHA-1, SHA-256, and SHA-512 with no data leaving your device. The guide on how online random generators actually work covers the entropy sources that underpin secure browser-based tools, which complements the security model that hashing depends on.
