Hash Generator Guide: MD5, SHA-1, SHA-256, SHA-512 Explained

Let's start with the basics: A hash function takes input data (any size — a single word, a whole book, a giant file) and produces a fixed-size string of bytes, typically rendered as hexadecimal.

I think of it like a digital fingerprint for data. Just like every person has a unique fingerprint, every piece of data has a unique hash (well, almost — we'll talk about that).

**The Critical Properties of a Good Hash Function:**

1. **Deterministic**: Same input always produces same output (no randomness!)

2. **One-way**: You can't reverse it — you can't get the original input from the hash

3. **Collision-resistant**: It should be extremely hard to find two different inputs that produce the same hash

4. **Avalanche effect**: A tiny change to the input (even changing one character!) completely changes the output

5. **Fixed-size**: The output is always the same length, no matter how big the input is

Let's see the avalanche effect in action — this is one of the coolest properties:

- Input: "Hello" → SHA-256: `185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969`

- Input: "hello" (lowercase h) → SHA-256: `2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824`

That one character change completely altered the hash! This is why hashes are so useful — even the smallest change is obvious.

You can try this yourself with our Hash Generator — it's a great way to see how these properties work in practice.

Not all hash functions are created equal. Some are fast, some are secure, some are broken but still useful for non-security purposes. Here's what you need to know:

**MD5 (128-bit output)**

- Fast — the fastest of these four

- **Cryptographically broken** — collisions can be found in seconds with modern hardware

- Still useful for checksums where security isn't a concern (e.g., checking for file corruption, not tampering)

- Never use MD5 for anything security-related (passwords, signatures, authentication)

- You'll still see it in older systems — but don't use it in new code!

**SHA-1 (160-bit output)**

- Also **cryptographically broken** — collisions were demonstrated in 2017

- Still common in legacy systems (old Git repositories, some certificate authorities)

- Better than MD5, but still not secure against modern attacks

- Use it only for compatibility with existing systems, not for new security features

**SHA-256 (256-bit output) — My Recommendation for Most Uses**

- Part of the SHA-2 family (the "Secure Hash Algorithm" family)

- Cryptographically secure — no known practical attacks as of 2026

- Fast enough for almost everything

- This is my default choice — if you're unsure, use SHA-256

- Widely supported in every programming language and tool

**SHA-512 (512-bit output)**

- Also SHA-2 family, twice the output size of SHA-256

- More secure against theoretical attacks (though SHA-256 is already very secure)

- Slower than SHA-256 (but still fast for most use cases)

- Good for high-security scenarios where you want the extra protection

- Note: On 64-bit systems, SHA-512 is often faster than SHA-256 — counterintuitive but true!

**What about SHA-3?**

SHA-3 is the newest member of the SHA family. It's great, but not as widely supported yet. Stick with SHA-256 or SHA-512 for now unless you have a specific reason to use SHA-3.

Let me be clear: MD5 and SHA-1 are broken for security. Don't use them for anything where security matters! Use our Hash Generator to try all these and see how the outputs differ.

I use hashes all the time. Here are the scenarios where they're the perfect tool for the job:

**1. Verifying File Integrity**

This is the classic use case. When you download a file, many websites publish the hash. Compute the hash of your downloaded file and compare.

If the hashes match, you can be confident the file wasn't corrupted or (if using a secure hash) maliciously modified in transit.

**2. Finding Duplicate Files/Data**

Instead of storing entire files to check for duplicates, just store the hashes! If two files have the same hash (for a secure hash function), they're almost certainly the same.

I've used this to de-duplicate backups, photo collections, and databases.

**3. Git and Version Control**

Git uses SHA-1 (and now SHA-256) for almost everything. Every commit has a hash, every file version has a hash. This is what makes Git so powerful.

**4. Content-Addressable Storage**

Store data by its hash! This is how IPFS, Docker, and many distributed systems work. The hash becomes the address — you can verify the content is correct by recomputing the hash.

**5. Signatures and Certificates**

Hashes are a key part of digital signatures. Instead of signing the whole (potentially large) document, you sign the hash of the document.

**6. Password Storage (But Wait — Not Alone!)**

You store a hash of the password, not the password itself. But you can't just use SHA-256 alone — you need a slow, salted hash like bcrypt, Argon2, or PBKDF2. More on this later.

**A common theme here:** Hashes are great when you need to know *if* something changed, or *identify* something uniquely, without storing the whole thing.

And remember: Hashes are NOT encryption. Encryption is reversible — hashes are not. You can't get the original data back from a hash.

Hashes are powerful, but they're not the solution to everything. Here's where I see people go wrong:

**1. Storing Passwords Without a Salt and Slow Hash**

This is a big one! If you just store `SHA256(password)`, you're vulnerable to rainbow table attacks. Always use:

- A unique salt per user (so identical passwords don't have identical hashes)

- A slow hash like bcrypt, Argon2, scrypt, or PBKDF2 (makes brute-force attacks expensive)

I cannot stress this enough: DO NOT use SHA-256 directly for password storage! Use a proper password hashing algorithm instead.

**2. Trying to Use Hashes as Encryption**

Hashes are one-way. They don't encrypt data — they digest it. If you need to get the original data back later, use encryption, not hashing.

**3. Using MD5 or SHA-1 for Security**

I've said it before, but I'll say it again: MD5 and SHA-1 are broken for security purposes. Use SHA-256 or SHA-512 instead.

**4. Using Hashes for Compression**

Hashes have a fixed size, but you lose the original data! That's not compression — that's destruction. Compression is reversible, hashing is not.

**5. Shortening Hashes and Expecting Security**

If you take a SHA-256 hash and only keep the first 8 characters, you drastically reduce collision resistance. Don't do this for security purposes.

**6. Assuming Hashes Are Unique (They Aren't, But They're Close)**

Collisions are theoretically possible (the pigeonhole principle: more possible inputs than outputs), but with SHA-256, the probability is so astronomically low that you don't have to worry about it in practice.

**The Rule of Thumb:** If you need to verify integrity in a non-security context: MD5 or SHA-1 are fine. If security is involved: use SHA-256 or SHA-512. If you're storing passwords: use bcrypt/Argon2/scrypt/PBKDF2.

Let's walk through the most common practical use case: verifying that a file you downloaded hasn't been corrupted or modified.

**Scenario:**

You download a Linux ISO from a website. The website says the SHA-256 hash is:

`9a0c2d6a1a5e4f3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2e1f0a9b`

**How to Verify (Command Line):**

**On macOS/Linux:**

# SHA-256
sha256sum your-file.iso

# MD5
md5sum your-file.iso

**On Windows (PowerShell):**

# SHA-256
Get-FileHash your-file.iso -Algorithm SHA256

# MD5
Get-FileHash your-file.iso -Algorithm MD5

**How to Verify (With Our Tool):**

For smaller files or text content, you can use our Hash Generator. Paste the text or upload a file, and it will compute the hash for you instantly.

**What If the Hashes Don't Match?**

- The file was corrupted during download — try downloading again

- The file was maliciously modified — DO NOT use it!

- You computed the hash of the wrong file — double-check

- The website published the wrong hash — verify from another source if possible

**Real-World Story:** I once downloaded a software update, and the hash didn't match. I was confused until I realized I had accidentally downloaded the previous version! Verifying the hash saved me from installing outdated software.

This is why publishing hashes is good practice for software downloads — it lets users verify they got exactly what was published.

Let's look at how to actually compute hashes in code. These are snippets I use regularly:

**Node.js:**

import crypto from 'crypto';

// Compute SHA-256 hash of a string
function sha256(input) {
  return crypto.createHash('sha256').update(input).digest('hex');
}

// Compute SHA-256 hash of a file
function sha256File(filePath) {
  return new Promise((resolve, reject) => {
    const hash = crypto.createHash('sha256');
    const stream = fs.createReadStream(filePath);
    stream.on('error', reject);
    stream.on('data', data => hash.update(data));
    stream.on('end', () => resolve(hash.digest('hex')));
  });
}

console.log(sha256('Hello, world!'));

**Python:**

import hashlib

def sha256(input_str):
    return hashlib.sha256(input_str.encode()).hexdigest()

def sha256_file(file_path):
    hash_obj = hashlib.sha256()
    with open(file_path, 'rb') as f:
        for chunk in iter(lambda: f.read(4096), b''):
            hash_obj.update(chunk)
    return hash_obj.hexdigest()

print(sha256('Hello, world!'))

**In the Browser:**

async function sha256(input) {
  const encoder = new TextEncoder();
  const data = encoder.encode(input);
  const hashBuffer = await crypto.subtle.digest('SHA-256', data);
  const hashArray = Array.from(new Uint8Array(hashBuffer));
  const hashHex = hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
  return hashHex;
}

sha256('Hello, world!').then(console.log);

Notice that for files, we read them in chunks — that's important so we don't load giant files into memory all at once.

And remember: Our Hash Generator can compute hashes for you quickly if you just need to do a one-off computation without writing code!

When talking about password storage (or hashing similar data), you'll hear about "salts" all the time. Let's make sure you understand what they are.

**What Is a Salt?**

A salt is a random string that you add to the input before hashing. And importantly, you use a different salt for every user.

**Why Salt?**

Without a salt, two users with the same password will have the same hash. An attacker can precompute hashes for common passwords (a rainbow table) and look up the matches.

With a unique salt per user, they can't — they have to crack each password individually.

**Example Without Salt:**

- User 1 password: "password123" → Hash: `a1b2c3...`

- User 2 password: "password123" → Hash: `a1b2c3...` (same! Uh-oh!)

**Example With Salt:**

- User 1 password + salt "xY7z9q" → Hash: `d4e5f6...`

- User 2 password + salt "k2m5n8" → Hash: `g7h8i9...` (different! Good!)

You store the salt alongside the hash — it's not a secret, just random data.

**But Wait:** Remember what I said earlier — don't just use SHA-256 with a salt. Use bcrypt, Argon2, scrypt, or PBKDF2. These handle salts for you, and they're designed to be slow to make brute-force attacks impractical.

**How Slow?** You want it to take 100ms-500ms per hash. That's fast enough for user login, but slow enough that an attacker can't try millions of passwords per second.

If you're storing passwords (and only if you have to!), use a library like bcrypt or argon2. Don't roll your own password storage system.

After years of working with hashes, here's my practical advice — use this as a cheat sheet:

**For File Checksums (Non-Security):**

- MD5 is fine (fast, widely supported), or SHA-256 if you want to be thorough

- Use our Hash Generator to compute them quickly

**For File Integrity With Security Concerns:**

- SHA-256 — my default choice

- SHA-512 if you want extra security

**For Git, Legacy Systems, Compatibility:**

- SHA-1 if you have to (but upgrade if you can)

**For Digital Signatures, Certificates:**

- SHA-256 or SHA-512

**For Password Storage:**

- 🚨 NOT SHA-256 directly! 🚨

- Use bcrypt, Argon2, scrypt, or PBKDF2

- These are slow, salted, and designed for passwords

**For Everything Else:**

- SHA-256 is your safe, fast, well-supported default

**One Last Note:** If you're using hashes for HMAC (like in webhook verification), use the same algorithm the provider specifies. HMAC-SHA256 is common and secure — we have an HMAC Generator for that too!

Hashes are one of those foundational concepts that you'll use again and again once you understand them. They're simple, powerful, and when used correctly, extremely useful.