Hash Generator: MD5, SHA-256, and When to Use Each Algorithm

Hashing comes up in more developer workflows than you might expect: verifying file downloads, storing passwords, generating cache keys, signing tokens, building deduplication systems. Each algorithm has a different profile — speed, security, output size, and purpose — and choosing the right one matters.

This guide covers the five algorithms in the hash generator, when to use each, how file hashing works in the browser, and the difference between hashing and encryption.

What Is a Hash Function?

A hash function takes input of any size and produces a fixed-size output (the “digest” or “hash”). The same input always produces the same output. A small change in the input produces a completely different output.

Key properties of a cryptographic hash:

1. Deterministic — same input, same output, every time
2. One-way — you cannot reverse a hash to get the original input
3. Avalanche effect — changing one bit in the input changes approximately half the output bits
4. Collision resistant — it’s computationally infeasible to find two different inputs that produce the same hash

The Five Algorithms

MD5

• Output: 128 bits (32 hex characters)
• Speed: Very fast
• Security: Broken — practical collision attacks exist

MD5 is cryptographically broken. It should not be used for security purposes. Do not use MD5 to hash passwords, sign data, or verify integrity against a determined attacker.

It’s still used for:

• Non-security checksums — verifying a file wasn’t corrupted in transit (not against tampering)
• Cache keys and fingerprinting — fast and consistent, good for identifying content internally
• Compatibility — some legacy systems require MD5 as an identifier format

The hash generator includes MD5 for completeness and compatibility with legacy workflows. The tool only supports MD5 for text input, not file input, to discourage using it in security-critical file verification contexts.

SHA-1

• Output: 160 bits (40 hex characters)
• Speed: Fast
• Security: Broken for collision resistance

SHA-1 was used extensively for years (SSL certificates, code signing, Git object IDs) but collision attacks have been demonstrated. Google published a practical collision in 2017 (SHAttered). Modern use cases are migrating away from SHA-1.

Still used in:

• Git — Git uses SHA-1 for object IDs (moving to SHA-256 in newer versions)
• Legacy systems — older APIs and protocols
• Compatibility checksums — when required by an external system

SHA-256

• Output: 256 bits (64 hex characters)
• Speed: Moderate
• Security: Current standard — no known attacks

SHA-256 is the workhorse of modern cryptography. It’s used in:

• Digital signatures — TLS/SSL certificates, code signing
• Password hashing (as a building block, not directly — use bcrypt/Argon2 for passwords)
• Blockchain — Bitcoin uses SHA-256
• File integrity — verifying downloads, build artifacts, container images
• HMAC — HS256 in JWT uses SHA-256 internally
• Content addressing — Docker image layers, Git (SHA-256 mode), IPFS

If you’re generating a hash for security or integrity purposes and don’t have a reason to use a specific algorithm, use SHA-256.

SHA-384

• Output: 384 bits (96 hex characters)
• Speed: Similar to SHA-512
• Security: Strong

SHA-384 is a truncated version of SHA-512. It’s used when:

• A larger digest than SHA-256 is desired but SHA-512’s full 512 bits is more than needed
• Compliance requirements specify SHA-384 (some TLS configurations, FIPS requirements)
• HS384 JWT signatures

SHA-512

• Output: 512 bits (128 hex characters)
• Speed: Similar to SHA-384
• Security: Strongest in the set

On 64-bit hardware, SHA-512 is often faster than SHA-256 because it processes more data per round. SHA-512 is used for:

• Maximum integrity assurance
• HS512 JWT signatures
• Large file integrity verification where overhead is acceptable

Choosing the Right Algorithm

File Hashing in the Browser

The File tab lets you hash any file locally in the browser using the SubtleCrypto API. No upload, no server — the file never leaves your machine.

Drop a file or click to browse. The tool reads the file as an ArrayBuffer and computes SHA-1, SHA-256, SHA-384, and SHA-512 simultaneously. (MD5 is not available for file input since the WebCrypto API doesn’t include MD5.)

Common file hashing workflows:

Verifying a downloaded file

Software downloads often publish SHA-256 checksums alongside the download:

sha256: a3b4c5d6e7f8a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a1b2c3d4e5f6a7b8

Drag the downloaded file into the tool, copy the SHA-256 output, and compare it against the published checksum. If they match, the file is intact. If they don’t, the download is corrupted or tampered with.

Generating checksums for release artifacts

If you’re publishing a tool, library, or binary, generate SHA-256 hashes of your release files and include them in the release notes. Users can verify the files they downloaded are exactly what you published.

Docker image verification

Docker image digests are SHA-256 hashes of the image manifest. If you pull a specific digest (docker pull image@sha256:abc123...), you’re getting exactly that image. Hash the relevant layer archives to confirm.

Deduplication

Generating SHA-256 hashes of files lets you identify duplicates — two files with the same hash are identical. This is how content-addressed storage systems (Git, IPFS, many backup tools) work.

Hex vs. Base64 Output

Hash digests are raw bytes. They’re typically displayed in two formats:

Hex (hexadecimal):

a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3

64 characters for SHA-256. Hex is the most common format for displaying hashes.

Base64:

pmWkWSBCL9JHNiQiM5fajDkTpZU+5xMI0ZNhNOOiCow=

43 characters for SHA-256 (33% more compact than hex). Base64 is used in HTTP headers (Authorization: Digest), JWT signatures, and compact representations. The Base64 guide covers the encoding format in depth, including the Base64URL variant used in JWT and URL-safe contexts.

The tool includes both representations, plus a toggle to switch all rows to Base64 simultaneously.

Compare A/B Mode

The hash generator includes a text comparison mode — enter two inputs and see their hashes side-by-side with a match/mismatch indicator for each algorithm.

Use cases:

Debugging serialization inconsistencies. You have two strings that look identical but hash differently. One probably has trailing whitespace, different line endings (\r\n vs \n), or a hidden Unicode character. The hashes confirm they’re different; the normalize input option helps identify the cause.

Verifying content equivalence across formats. Two files generated by different processes should have the same content. Compare their hashes to confirm.

Testing hash implementations. You’re implementing SHA-256 in a new language or library. Compare your output against a known-good result.

The Normalize Input Option

Text hashing can be sensitive to:

• Trailing whitespace (a trailing space changes the hash)
• Line endings (\r\n on Windows vs \n on Unix)
• Leading/trailing newlines

The “Normalize input” toggle trims whitespace from both ends and normalizes all line endings to \n. This is useful when comparing hashes of text content that might have been created or copied in different environments.

Hashing vs. Encryption

These are commonly confused:

Hashing:

• One-way — cannot be reversed
• Fixed output size
• Same input always produces same output
• Purpose: fingerprinting, integrity verification, deduplication

Encryption:

• Two-way — can be decrypted with the key
• Output size varies (or is larger than input)
• Requires a key
• Purpose: confidentiality

What this means for passwords: Never store passwords as hashes from these algorithms (MD5, SHA-*, etc.). These algorithms are designed to be fast, which makes them easy to brute-force. Use a password hashing function specifically designed to be slow: bcrypt, Argon2, or scrypt.

SHA-256 of a password is not secure password storage. bcrypt of a password is.

HMAC: Keyed Hashing

A regular hash is a fingerprint of the content. An HMAC (Hash-based Message Authentication Code) is a fingerprint of the content combined with a secret key. Without the key, you can’t generate a valid HMAC.

HMACs are used for:

• JWT signatures (HS256, HS384, HS512)
• API request signing
• Webhook payload verification (GitHub, Stripe, Shopify all use HMAC-SHA256)

For decoding and verifying JWT tokens directly in the browser — including HMAC signature verification against a known secret — the JWT Decoder guide covers the full inspection workflow including expiry checking and claims rendering.

The hash generator’s HMAC tab lets you generate HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 from text input with a secret key. The output is available in both hex and base64.

For verifying a webhook, the workflow is:

1. Enter the raw webhook body as input
2. Enter your signing secret as the key
3. Generate the HMAC-SHA256
4. Compare against the signature in the webhook header

Generating Hashes Programmatically

Understanding what the hash generator outputs helps you reproduce the same results in code:

JavaScript (Web):

const encoder = new TextEncoder();
const data = encoder.encode("Hello, world");
const hashBuffer = await crypto.subtle.digest("SHA-256", data);
const hashHex = Array.from(new Uint8Array(hashBuffer))
  .map(b => b.toString(16).padStart(2, "0"))
  .join("");

Python:

import hashlib
digest = hashlib.sha256("Hello, world".encode()).hexdigest()

C#:

using System.Security.Cryptography;
var bytes = SHA256.HashData(System.Text.Encoding.UTF8.GetBytes("Hello, world"));
var hex = Convert.ToHexString(bytes).ToLower();

The hash generator uses the same SubtleCrypto API as the JavaScript example above. Results will match across all three if the input encoding is consistent (UTF-8).

The hash generator covers the full range of common developer hashing needs — file verification, text fingerprinting, HMAC generation, and comparison. Pick the algorithm that matches your use case, and remember: for passwords, use a dedicated password hashing library, not these algorithms directly.