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

Understand the difference between MD5, SHA-1, SHA-256, and SHA-512. Generate file and text hashes instantly in your browser. Learn when each algorithm is appropriate.

Every time you download a software release, verify a file's authenticity, sign a JWT token, or store a user's password, a cryptographic hash function is working in the background. Hash functions are one of the foundational primitives of modern computing security — and yet the differences between MD5, SHA-1, SHA-256, and SHA-512 are widely misunderstood, leading to real security mistakes in production systems.

This guide explains what hash functions are, how each major algorithm works, when each is appropriate (and when it is dangerously inappropriate), and how to use the SoftStash Hash Generator to compute hashes instantly in your browser with full privacy.

What Is a Cryptographic Hash Function?

A cryptographic hash function takes an input of arbitrary length and produces a fixed-length output called a digest or hash. Four properties define a good cryptographic hash function:

Deterministic: The same input always produces exactly the same output. Hash functions have no internal state — given the same bytes, you always get the same digest.
One-way (preimage resistance): Given a hash output, it should be computationally infeasible to recover the original input. Hash functions are designed to be easy to compute in one direction and effectively impossible to reverse.
Fixed output length: Regardless of whether the input is one byte or one gigabyte, the output is always the same length. SHA-256 always produces a 256-bit (32-byte) digest.
Avalanche effect: A single-bit change in the input completely transforms the output. The hash of hello looks nothing like the hash of hello! — they share zero predictable structure. This makes hashes useful as fingerprints.

A fifth property — collision resistance — separates cryptographically strong hashes from broken ones: it should be computationally infeasible to find two different inputs that produce the same output. This is where MD5 and SHA-1 have failed.

MD5: Fast, Ubiquitous, and Broken for Security

MD5 (Message Digest 5) was designed by Ron Rivest and published in 1991. It produces a 128-bit (16-byte) digest, typically represented as a 32-character hexadecimal string like 5d41402abc4b2a76b9719d911017c592. For over a decade it was the dominant hash algorithm for everything from file checksums to password storage.

In 2004, cryptographers demonstrated practical collision attacks against MD5. By 2008, researchers had used collision attacks to forge a rogue certificate authority certificate trusted by all major browsers. MD5 is now definitively broken for any security purpose where collision resistance matters.

Where MD5 is still acceptable:

Non-security file integrity checks where you control both the generation and verification (confirming a file wasn't corrupted in transit, not that it wasn't tampered with).
Checksums in internal systems where a bad actor is not in the threat model.
Legacy system compatibility where you have no choice but to match an existing implementation.
Cache keys and hash maps where security is irrelevant and speed matters.

Where MD5 must never be used: TLS certificates, digital signatures, code signing, or anything where an attacker might benefit from finding a collision.

SHA-1: 160-Bit, Deprecated, Still Everywhere

SHA-1 (Secure Hash Algorithm 1) was published by NIST in 1995 and produces a 160-bit digest. It was the standard for TLS certificates, digital signatures, and software signing throughout the 2000s. Google's Project Zero demonstrated a practical SHA-1 collision in 2017 (the SHAttered attack), producing two different PDF files with identical SHA-1 hashes. This ended SHA-1's use in TLS — all major browser vendors stopped accepting SHA-1 certificates that same year.

SHA-1 is still found in some notable places:

Git: Git has historically used SHA-1 to identify every object in a repository — commits, blobs, trees, and tags. Git is actively migrating to SHA-256 (see below), but SHA-1 Git repositories remain extremely common. For this use case, collision resistance matters less because an attacker would need filesystem access to exploit a collision.
Legacy authentication systems and older HMAC implementations.
Some older enterprise software that has not been updated.

For any new work: avoid SHA-1. Use SHA-256 or SHA-512.

SHA-256: The Current Standard

SHA-256 is part of the SHA-2 family, published by NIST in 2001. It produces a 256-bit (32-byte) digest — twice the output length of MD5 and 60% larger than SHA-1. No practical collision or preimage attacks against SHA-256 have been demonstrated. It remains the standard for security-sensitive hashing in 2026.

SHA-256 is used everywhere:

TLS certificates: The CA/Browser Forum mandated SHA-256 as the minimum for certificate signatures. Every HTTPS connection you make is anchored by SHA-256.
Code signing: macOS, Windows Authenticode, and Linux package managers (APT, RPM) use SHA-256 to verify software integrity.
JWT tokens: The HS256 algorithm in JSON Web Tokens is HMAC-SHA-256. It is by far the most common JWT signing algorithm in deployed systems.
Bitcoin: Bitcoin's proof-of-work algorithm is double-SHA-256 (SHA-256 applied twice).
Git (next generation): Git's SHA-256 object format (enabled with --object-format=sha256) uses SHA-256 for all object IDs.
File integrity verification published alongside software downloads.

If you need to pick a hash function and have no specific constraints, SHA-256 is the correct default choice in 2026.

SHA-512: Larger Output, Sometimes Faster

SHA-512 is also part of the SHA-2 family and produces a 512-bit (64-byte) digest. It provides a larger security margin than SHA-256 — 512 bits of output means the theoretical brute-force attack space is 2²⁵⁶ times larger. In practice, this additional margin is irrelevant for most applications since SHA-256 is already computationally infeasible to break.

The counterintuitive performance characteristic: SHA-512 is faster than SHA-256 on modern 64-bit CPUs when hashing large data. SHA-512 processes data in 1024-bit blocks with 64-bit word operations, while SHA-256 uses 512-bit blocks with 32-bit operations. On a 64-bit processor, the 64-bit operations map more efficiently to hardware. This makes SHA-512 the preferred choice for applications that hash large files on 64-bit servers.

Use SHA-512 when:

You are hashing large amounts of data on 64-bit hardware and want maximum throughput.
Your system requires the additional security margin for regulatory or compliance reasons.
You are implementing HMAC-SHA-512 (used in some JWT implementations with HS512).

Algorithm Comparison Table

Algorithm	Output Length	Speed (relative)	Security Status	Common Use Cases
MD5	128-bit (32 hex chars)	Fastest	Broken — collisions demonstrated	Non-security checksums, cache keys, legacy systems
SHA-1	160-bit (40 hex chars)	Fast	Deprecated — practical collisions exist	Legacy Git, old TLS (deprecated), some legacy auth
SHA-256	256-bit (64 hex chars)	Fast	Secure — current standard	TLS certificates, JWT (HS256), code signing, Bitcoin
SHA-512	512-bit (128 hex chars)	Fastest on 64-bit for large data	Secure — larger safety margin	Large file hashing, JWT (HS512), high-security applications

File Integrity Verification: A Practical Example

One of the most common and legitimate uses of cryptographic hashes is verifying that a downloaded file is exactly what the publisher intended — not corrupted in transit and not tampered with by a third party. Most major software projects publish SHA-256 checksums alongside their downloads.

The workflow looks like this:

Download the file from the official source.
Download the published checksum from the same official source (ideally signed with PGP).
Compute the SHA-256 hash of the downloaded file.
Compare your computed hash to the published hash character by character. Any difference means the file is not what the publisher distributed.

The SoftStash Hash Generator supports file hashing — drag in a file and it will compute the hash locally in your browser without uploading anything. Compare the result directly to the published checksum.

Password Storage: The One Thing Hashes Cannot Do Safely

Critical Warning: Never Store Passwords Using Plain Hash Functions

Storing passwords as MD5, SHA-256, or SHA-512 hashes — even with a salt — is insecure and a serious vulnerability in any production system. Here is why:

General-purpose hash functions are designed to be fast. A modern GPU can compute billions of SHA-256 hashes per second. If your database is breached, an attacker can brute-force every common password in minutes.
Rainbow tables — precomputed lookup tables mapping hashes to inputs — can crack unsalted hashes of common passwords in milliseconds.
Even with a unique salt per user, the raw speed of SHA-256 makes it easy to attack weak or medium-strength passwords at scale.

Use a password hashing function instead: bcrypt, scrypt, or Argon2 (the winner of the Password Hashing Competition). These are deliberately slow and memory-intensive, making brute-force attacks orders of magnitude more expensive. Most modern frameworks include them out of the box. Argon2id is the current recommendation for new systems.

How Git Uses SHA-1 (and Is Moving to SHA-256)

Git uses a hash function to identify every object in a repository. Every commit, file (blob), directory listing (tree), and tag is stored in the object database under its SHA-1 hash. When you run git log, the long hex strings you see — like c206f4b3a9d72bc0e53a0e1a6e4bdf8c7f9d2e51 — are SHA-1 hashes of commit objects.

Git chose SHA-1 in 2005 for speed and because at the time SHA-1 was not broken. The role of hashes in Git is slightly different from traditional security use: Git uses them as content-addressable storage keys, not authentication proofs. The content itself is what you trust — the hash is just an efficient way to look it up and detect accidental corruption.

After the SHAttered SHA-1 collision in 2017, the Git project began work on transitioning to SHA-256. The new object format (--object-format=sha256) is available in Git 2.29+ and is used by default in some new repository hosts. Existing repositories can be migrated, though the transition is complex because every object ID changes.

HMAC: Hash-Based Message Authentication

A plain hash verifies data integrity (the data has not changed) but not authenticity (the data came from who you think it came from). If an attacker can intercept a message and recompute the hash after modifying it, a plain hash provides no protection.

HMAC (Hash-based Message Authentication Code) solves this by incorporating a secret key into the hash computation. The result can only be produced by someone who knows the key. Verifying an HMAC proves both that the data is intact and that it was produced by a party with access to the shared secret.

HMAC-SHA256 is everywhere:

JWT tokens (HS256): The server signs the token header and payload with HMAC-SHA256 using a secret key. Clients cannot forge valid tokens without the key.
API request signing: AWS Signature Version 4 uses HMAC-SHA256 to authenticate API requests. The request details and a derived signing key are hashed together so neither can be modified without invalidating the signature.
Cookie integrity: Many web frameworks use HMAC to sign session cookies, preventing users from tampering with their own session data.

How to Use the SoftStash Hash Generator

The Hash Generator supports hashing both text input and file uploads entirely in your browser. Here is how it works:

Text hashing: Paste any text into the input field. The tool immediately computes and displays the hash for every supported algorithm simultaneously — MD5, SHA-1, SHA-256, and SHA-512 — so you can compare them side by side and choose the one you need.
File hashing: Click the file input or drag and drop any file. The file is read by your browser's File API and hashed locally. Large files are processed in chunks to avoid memory pressure. No bytes of your file leave your device.
Choose algorithm: Select the specific algorithm to focus on for your use case. The full hex digest is displayed and can be copied with one click.
Download as file: For documentation or distribution purposes, export the hash digest as a text file — useful for publishing checksums alongside your own software releases.

Privacy: The Web Crypto API

Everything stays on your device. The SoftStash Hash Generator uses the browser's built-in window.crypto.subtle API (the Web Crypto API) to compute SHA-family hashes. This is native cryptography implemented by your browser's C++ engine — not JavaScript math. For MD5, a pure JavaScript implementation runs locally. In both cases, no data — not a single byte of your text or file content — is ever transmitted to SoftStash servers or any third-party service. Hash computation happens entirely within your browser process.

Choosing the Right Algorithm: A Decision Guide

File integrity / checksums (non-security): MD5 or SHA-256. SHA-256 is preferred for anything public-facing even if the threat model is only accidental corruption, since using a broken algorithm by choice is hard to justify to auditors.
TLS, code signing, certificate operations: SHA-256 (mandatory — SHA-1 is rejected).
JWT signing: HMAC-SHA-256 (HS256) for symmetric, or RS256/ES256 for asymmetric. Never MD5 or SHA-1.
Password storage: Argon2id, bcrypt, or scrypt. Not SHA-anything.
Large file hashing on 64-bit servers: SHA-512 for best throughput.
Maximum security margin: SHA-512 or SHA-3 (SHA3-256, SHA3-512).
Legacy compatibility: Whatever the legacy system requires — but plan the migration away from MD5 and SHA-1.

Generate MD5, SHA-1, SHA-256 and SHA-512 hashes instantly

Paste text or drop a file. All hashing happens in your browser using the Web Crypto API. Nothing is uploaded. Nothing is logged.

Open Hash Generator →