A hash function takes any input - a password, a file, an API request body - and returns a fixed-length string of characters. Run the same input again, you get the same output. Change a single character, and you get a completely different output. That deterministic, chaotic behavior is what makes hashes useful.
Not all hash algorithms are created equal. MD5 and SHA-1 show up in legacy systems but should not be trusted for security-sensitive work. SHA-256 is today's standard. SHA-512 exists for when 256 bits of output isn't enough headroom. Knowing which to reach for, and why, keeps you from picking the wrong tool for a job where the stakes are real.
Photo by Google DeepMind on Pexels
What a Hash Function Actually Does
Hash functions convert arbitrary-length input into a fixed-length output called a digest. SHA-256 always returns 64 hex characters (256 bits). SHA-512 always returns 128 hex characters (512 bits). MD5 always returns 32 hex characters (128 bits).
Three properties define a cryptographic hash function:
One-way. You can compute a hash from input, but you cannot derive the original input from its hash. This is what makes hash functions useful for password storage: the database never needs to store the actual password.
Deterministic. The same input always produces the same output. This is what makes file integrity checks possible. Hash the file before transmission, hash it again on receipt, compare. If they match, the file wasn't tampered with.
Avalanche effect. A single-bit change in input produces a completely different hash. Change one character in a 1,000-word document and the hash is unrecognizable compared to the original. This property is critical for detecting tampering.
A fourth property, collision resistance, is where the algorithms diverge. A collision means two different inputs produce the same hash output. In a secure hash function, collisions don't exist in any practical sense. MD5 and SHA-1 failed this test.
The Four Algorithms Worth Knowing
MD5: Fast, Familiar, and Compromised for Security
MD5 was designed in 1991 and produces a 128-bit digest. It's fast, which made it popular for file checksums and quick integrity verification.
The problem: cryptographic collisions in MD5 have been demonstrated in practice. Researchers can generate two different files with the same MD5 hash in minutes on consumer hardware. For file integrity on untrusted networks, MD5 is not safe. For password storage, MD5 is dangerous.
For checksum verification of files you generated yourself in a trusted environment, MD5 is still technically functional. But you might as well use SHA-256 out of habit. The speed advantage doesn't matter at human scale, and you avoid carrying around a weak-algorithm dependency.
Photo by MD5 persists because of backward compatibility. Legacy databases, old build systems, and some CDNs still use it. If you're auditing existing infrastructure, expect to see MD5. If you're choosing an algorithm for new work, skip it.
SHA-1: Better Than MD5, Heading the Same Direction
SHA-1 produces a 160-bit digest and was the dominant checksum algorithm through the 2000s. Git still uses SHA-1 internally for object identification, though it's gradually migrating to SHA-256.
SHA-1 collision attacks moved from theoretical to practical around 2017, when researchers demonstrated a real-world collision (the SHAttered attack). Browsers stopped trusting SHA-1 TLS certificates years before that. If SHA-1 shows up in a security context, treat it as a red flag.
For non-security checksums where you need compatibility with older tooling, SHA-1 is in a similar category to MD5: functional but leaving you a migration headache later.
SHA-256: The Current Standard
SHA-256 produces a 256-bit digest and is part of the SHA-2 family. This is the algorithm you should default to unless you have a specific reason to pick something else. It's widely supported, well-audited, and has no known practical vulnerabilities.
SHA-256 is what most modern TLS certificates use, what Bitcoin's proof-of-work mechanism uses, and what HMAC-SHA256 is built on. If you're writing an API and need to sign requests, HMAC-SHA256 is the right choice for most applications.
"When I see a client using MD5 or SHA-1 for anything beyond legacy compatibility, it's usually because they haven't thought through the security requirements. SHA-256 has been the safe default for years, and unlike MD5, you won't be scrambling to migrate when someone demonstrates a practical collision attack." - Dennis Traina, founder of 137Foundry
SHA-512: More Bits, Specific Use Cases
SHA-512 produces a 512-bit digest. On 64-bit hardware, SHA-512 is often faster than SHA-256 because of how the arithmetic maps to 64-bit word sizes. This surprises developers who assume more bits means more computation time.
SHA-512 makes sense when you want extra collision resistance headroom in long-lived systems, or when you're building something that needs to remain secure against hardware advances over decades. For most web applications, SHA-256 is more than sufficient.
HMAC: Hashing With a Secret Key
HMAC (Hash-based Message Authentication Code) wraps a hash function with a secret key. HMAC-SHA256 is the standard for API request signing.
The point of HMAC is authentication, not just integrity. A plain SHA-256 hash tells you the data hasn't been corrupted. An HMAC tells you the data came from someone who knows the secret key. Without the key, an attacker can't forge a valid HMAC for modified data, even if they can observe legitimate requests.
Stripe, GitHub, and Shopify all use HMAC-SHA256 for webhook signatures. When they send a webhook to your endpoint, they include a signature computed with their secret key. You compute the same HMAC with the shared key on your end and compare. If the signatures match, the request is legitimate.
You can use https://evvytools.com/tools/dev-tech/hash-generator/ to generate HMAC-SHA256 signatures with a custom secret key, which is useful when you're debugging webhook verification logic or confirming your implementation matches expected output.
Password Hashing Is a Different Problem
A common misconception: developers hear "hash passwords" and reach for SHA-256. That's the wrong tool.
SHA-256 and SHA-512 are designed to be fast. For password hashing, fast is a liability. An attacker with a GPU can compute billions of SHA-256 hashes per second, which makes brute-forcing a stolen password database feasible.
Password-specific algorithms like bcrypt, scrypt, and Argon2 are intentionally slow and memory-intensive. They're designed so that legitimate logins still happen quickly (milliseconds) but brute-force attacks take years rather than hours.
For password storage, use one of those algorithms, not SHA-256. SHA-256 is appropriate in a password context only as a component inside a proper key derivation function, not as the whole function.
Photo by ThisIsEngineering on Pexels
Checking Hashes in Practice
File integrity verification is the clearest everyday use case. You download a binary from a project's release page. The project lists the expected SHA-256 hash alongside the download. You hash the file you received and compare. If they match, the file wasn't corrupted or tampered with in transit.
This is particularly important when downloading software from a mirror rather than the original source. The hash published by the project authors is your ground truth, and any mirror is only trustworthy if the hash checks out.
API request signing follows the same pattern. Before sending a request, you compute an HMAC over the request body using a shared secret. The server does the same computation and checks the result. This prevents both tampering and replay attacks when combined with a timestamp in the signed payload.
The EvvyTools tools directory covers hash generation, file integrity checking, and a range of developer utilities that fit into security workflows. The Hash Generator handles MD5, SHA-1, SHA-256, SHA-512, and HMAC-SHA256 entirely client-side. Your input never leaves your browser, which matters when you're working with sensitive data or testing production keys.
Choosing the Right Algorithm
The decision tree is short. For security-sensitive work including API signatures, file verification on untrusted channels, and token generation, use SHA-256. No exceptions for new work.
For legacy compatibility where existing systems use MD5 or SHA-1, document the risk and plan the migration. Don't extend the usage to new surfaces.
For password storage, SHA algorithms are the wrong category entirely. Use bcrypt, scrypt, or Argon2.
For HMAC and API signing, HMAC-SHA256 is what the major API platforms use, which means the tooling around it is mature and well-documented.
For extra collision resistance in long-lived systems, SHA-512 is available. SHA-256 is probably sufficient for most applications, but SHA-512 gives you headroom if you're designing something meant to last decades.
One practical note: if you're picking an algorithm for something that will be hard to migrate later, such as stored database records or archived signed documents, err toward SHA-256 over MD5 or SHA-1 even if the security risk currently seems low. The migration cost of switching algorithms in a system with millions of records far exceeds the cost of using the better option from the start.
The EvvyTools blog covers related developer topics including JWT decoding, DNS lookup tools, and password entropy. If you're building out a security audit workflow, the breadth of tools helps keep related diagnostics in one place.
Where These Algorithms Show Up in the Wild
You'll encounter SHA-256 in TLS certificates visible in your browser's connection details, in every major cryptography library, and in the SHA-2 specification on Wikipedia. NIST maintains current cryptographic standards and publishes recommendations for which algorithms remain approved. Their guidance is worth checking when you're making a long-term architecture decision that involves picking a hash algorithm.
MD5 is documented in detail including the history of its collision vulnerabilities at Wikipedia's MD5 article. The OWASP cheat sheets cover cryptographic storage practices and are a reliable reference when you're building anything that handles credentials or sensitive data.
Photo by Vadim Koza on Pexels
Understanding which algorithm to use, and why the older ones fell from favor, is the foundation. A reliable way to generate and verify hashes quickly without sending data to an external server is the next practical step.
