What a cryptographic hash function actually does
A hash function takes an input of any size — a single character or a multi-gigabyte file — and produces a fixed-size output: 128 bits for MD5, 160 bits for SHA-1, 256 bits for SHA-256, always shown here as hexadecimal since that's the standard way to write raw bytes as text. The same input always produces the same output, a tiny change to the input (even one bit) produces a completely different output with no visible pattern connecting the two, and — for a properly designed hash — there's no practical way to work backward from the output to any input that produces it, or to find two different inputs that produce the same output.
Why MD5 and SHA-1 are still here at all
Both were designed as cryptographically secure hashes and were treated that way for years — MD5 through the 1990s, SHA-1 into the 2000s. Both are now broken in the specific sense that matters for security: researchers have demonstrated practical collision attacks, meaning it's computationally feasible to construct two different inputs that hash to the same value. That's fatal for anything relying on a hash to prove a file or message hasn't been tampered with, since an attacker can construct a malicious file with the same hash as a legitimate one. What it doesn't break is their use as fast, well-known checksums — detecting accidental corruption, deduplicating files by content, or generating a short cache key from a longer string — none of which depend on an adversary being unable to engineer a collision on purpose.
Why SHA-256 is the one still considered secure
SHA-256, part of the SHA-2 family designed by the NSA and published in 2001, has no known practical collision or preimage attack as of this writing, and is the algorithm behind Bitcoin's proof-of-work, TLS certificate fingerprints, and most modern software package integrity checks. Its 256-bit output also gives it a far larger space to search than MD5's 128 bits or SHA-1's 160 — doubling the output size roughly squares the effort needed for a brute-force collision search, which is why the jump from 128 to 256 bits represents a much bigger practical security margin than the bit counts alone suggest.
How this tool computes MD5 without a native browser API
Browsers implement the Web Crypto API's crypto.subtle.digest() for SHA-1 and SHA-256 (and the rest of the SHA-2 family), which this tool uses directly — that's real, browser-native, hardware where available cryptographic code, not a JavaScript reimplementation. MD5 was deliberately left out of that API specification because it's considered broken, so there's no built-in browser primitive to call. This tool implements the MD5 algorithm (RFC 1321) directly in JavaScript instead, verified against the standard published test vectors and cross-checked byte-for-byte against an independent reference implementation across dozens of input lengths, including the exact boundary lengths where MD5's internal block-padding logic is most likely to hide an off-by-one bug.
Text versus file hashing
Hashing text encodes it as UTF-8 bytes first (the same encoding used throughout this site's other text/hex tools), since a hash function operates on raw bytes, not on the abstract idea of a string — the exact same visible text can hash differently depending on which byte encoding produced it. File hashing reads the file's raw bytes directly, with no encoding step, which is exactly what "the MD5 of this download" or "the SHA-256 checksum on the release page" means in practice: a hash of the file's literal byte content, letting anyone who downloads it confirm they received exactly those bytes and nothing was corrupted or substituted in transit.
Where each algorithm actually gets used today
MD5 persists in non-security contexts where its 128-bit output and speed are convenient: some version-control and deduplication systems, ETag headers for HTTP caching, and legacy checksums on older software distributions that predate the collision research. SHA-1 shows up similarly in legacy contexts (Git famously used it for commit hashes for years, and has been migrating away specifically because of the collision risk). SHA-256 is what current software distributions, package managers, and TLS certificate infrastructure actually rely on for integrity verification today — if a checksum on a download page is described as a "SHA-256 checksum" or "SHA256SUMS" file, comparing it against this tool's SHA-256 output is exactly the intended verification step.