Hash Generator Online — MD5, SHA-1, SHA-256 & SHA-512 Free

What Is a Cryptographic Hash Function?

A cryptographic hash function takes any input — a single character, a document, an entire disk image — and produces a fixed-length output called a hash, digest, or checksum. The output length is fixed regardless of input length: whether you hash one byte or one gigabyte with SHA-256, you always get a 256-bit (64 hex character) result.

Four key properties define a cryptographically useful hash function:

• Deterministic: The same input always produces the same hash. "hello" always produces the same SHA-256 value regardless of when or where it is computed.
• One-way (preimage resistant): Given a hash, it is computationally infeasible to work backwards to find the original input. This property is why hashes are used to store passwords — the database stores the hash, not the password itself.
• Avalanche effect: A tiny change to the input completely transforms the hash. Changing a single bit in the input causes approximately half of all bits in the output to flip. "hello" and "Hello" produce completely different hashes despite differing by only one bit.
• Collision resistant: It should be computationally infeasible to find two different inputs that produce the same hash (a collision). If collisions can be found efficiently, the hash function is considered broken for security purposes.

Hash Algorithm Comparison

How to Use the Hash Generator

1. Select the hash algorithm. Choose from MD5, SHA-1, SHA-256, SHA-384, SHA-512, or others depending on your purpose.
2. Enter your text. Type or paste any text into the input field. The hash updates in real time as you type, which clearly demonstrates the avalanche effect.
3. Copy the hash. Click the copy button to copy the hash to your clipboard. Hashes are case-insensitive but conventionally written in lowercase hexadecimal. Some systems (Windows file checksums, for example) display them in uppercase.

What Hash Functions Are Used For

File integrity verification

When you download software, operating system ISOs, or large files from the internet, the download host often provides a SHA-256 checksum alongside the file. After downloading, you compute the hash of your downloaded file and compare it to the published value. If they match, the file is exactly as the host intended — it was not corrupted in transit and was not tampered with by an intermediary. This is called an integrity check.

Note that integrity verification does not verify authenticity (that the file came from a trusted source) — that requires a digital signature using asymmetric cryptography in addition to a hash. Most reputable software publishers provide both a checksum and a cryptographic signature.

Digital signatures and certificates

Digital signatures work by first hashing the message or document, then encrypting the hash with the sender's private key. The recipient decrypts the hash with the sender's public key and computes the hash of the received message independently — if the two hashes match, the signature is valid. The security of digital signatures therefore depends on the collision resistance of the hash function: if two different messages can produce the same hash, an attacker could swap them without detection.

This is why SHA-1's 2017 "SHAttered" collision attack (where researchers at Google and CWI produced two different PDF files with the same SHA-1 hash) was a significant event: it demonstrated that SHA-1-based digital signatures could theoretically be forged. Certificate authorities and browser vendors immediately accelerated the retirement of SHA-1 in TLS certificates.

Blockchains and proof of work

Bitcoin's proof-of-work consensus mechanism uses SHA-256 double hashing (SHA-256 applied twice). Miners compete to find an input (nonce) that, when added to a block header and hashed, produces an output starting with a certain number of zero bits. The difficulty adjusts so that finding a valid hash takes approximately 10 minutes for the entire network. Because SHA-256 is one-way, the only way to find a valid nonce is to try billions of values — this is what mining hardware does.

Ethereum historically used Keccak-256 (a variant of SHA-3) for its proof-of-work and continues to use it in its transaction hashing and address derivation after the transition to proof-of-stake.

Data structures

Hash functions are the basis of hash tables (the data structure underlying Python dictionaries, JavaScript objects, and Java HashMaps). In this context, the hash function is used to convert a key into an index in an array for fast lookup. These applications use non-cryptographic hash functions (MurmurHash, xxHash, FNV) that prioritise speed and distribution over security properties.

Merkle trees use repeated hashing to create a tree of hashes where each parent node is the hash of its children. This structure allows efficient and secure verification of large datasets (used in Git, Bitcoin, and distributed storage systems like IPFS) — you can verify whether a specific file is part of a dataset using only a logarithmic number of hashes rather than the entire dataset.

Why MD5 and SHA-1 Are Broken for Security

MD5 was broken for collision resistance in 2004 when researchers demonstrated that two different files could be engineered to produce the same MD5 hash. This was not a lucky find — the attack was efficient enough to run on a laptop in hours. By 2008, researchers had created a rogue CA certificate with the same MD5 hash as a legitimate one, demonstrating a real-world forgery attack. MD5 should never be used for any security-critical purpose.

SHA-1 held up longer but fell in 2017 with the SHAttered attack. The Google/CWI team produced two different PDF files with the same SHA-1 hash using approximately 110 GPU-years of computation — expensive but within the reach of well-resourced attackers, and costs have declined since. Major CAs stopped issuing SHA-1 certificates in 2016 (Google Chrome started rejecting them); by 2020, essentially no publicly trusted systems still used SHA-1 for certificates.

Despite being broken for security, MD5 remains widely used for non-security purposes: cache invalidation keys, ETags in HTTP, deduplication of files, and generating short identifiers. In these contexts, the collision vulnerability is irrelevant because no adversary is trying to create a collision — you are just checking whether two files are byte-for-byte identical. MD5 is fast and still reliable as a change-detection mechanism.

How Password Hashing Works

When a website stores your password, it should not store the password itself (plaintext storage) or a simple hash of the password (unsalted hash). Instead, it should use a purpose-built password hashing function. Here is why each approach differs:

Why plain SHA-256 is wrong for passwords

General-purpose hash functions like SHA-256 are intentionally designed to be fast — they can compute billions of hashes per second on GPU hardware. If an attacker obtains a database of SHA-256-hashed passwords, they can run billions of guesses per second, trying every common password and dictionary word in seconds. The entire "rockyou" password list (14 million passwords) can be exhaustively checked in under a second with GPU hardware.

Salting

A salt is a random value generated uniquely for each user and stored alongside the hash. The password is combined with the salt before hashing: hash(password + salt) or hash(salt + password). This has two effects: identical passwords produce different hashes (preventing an attacker from noticing that two users share the same password), and precomputed rainbow tables (mappings of known inputs to hashes) become useless because they were not computed with each user's unique salt. Salting is necessary but not sufficient — an attacker can still crack salted passwords by computing hashes for each salt individually.

Purpose-built slow hash functions

The real solution is to use a hash function that is intentionally slow, making brute-force attacks computationally expensive:

• bcrypt: Introduced in 1999; includes a configurable work factor that increases the time per hash. A work factor of 12 means each hash takes approximately 0.3 seconds on modern hardware. At 0.3 seconds per guess, 14 million passwords would take 50 days to check — making attacks impractical.
• scrypt: Designed to be memory-hard as well as compute-hard, making it resistant to GPU and ASIC attacks that can throw massive parallel compute at bcrypt.
• Argon2: Winner of the 2015 Password Hashing Competition. Three variants: Argon2i (resistance to side-channel attacks), Argon2d (maximum resistance to GPU cracking), and Argon2id (a hybrid recommended for most applications). Argon2id is the current best-practice recommendation from OWASP.
• PBKDF2: NIST-recommended; applies a hash function (usually SHA-256) a configurable number of times. Less memory-hard than Argon2 or scrypt, but widely supported and compliant with federal standards.

If you are building a web application, your framework handles password hashing internally — Django uses PBKDF2 by default, bcrypt optionally; Rails uses bcrypt; many Node.js apps use bcrypt via the bcryptjs library. Never implement password hashing yourself using raw SHA-256 or MD5. Use the password generator to create strong passwords for your users to begin with.

Hash vs Checksum vs Encryption

These three terms are sometimes confused:

• Hash: One-way transformation. A hash cannot be reversed to obtain the original input. Used for integrity verification and password storage.
• Checksum: Any value used to verify data integrity. A checksum can be a cryptographic hash (SHA-256) or a simpler non-cryptographic value (CRC32, Adler-32). In casual usage, "checksum" often means "file hash" but technically includes simpler integrity values not suitable for security purposes.
• Encryption: Two-way transformation. Encrypted data can be decrypted back to the original given the correct key. Encryption is used to protect data in transit and at rest. Encrypting a password is wrong for password storage — if the encryption key is compromised, all passwords are immediately exposed. Hashing is correct because it cannot be reversed even with full database access.

Generating Hashes in Different Programming Languages

// JavaScript (Node.js)
const crypto = require('crypto');
const hash = crypto.createHash('sha256').update('hello').digest('hex');
// → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

# Python
import hashlib
hash = hashlib.sha256(b'hello').hexdigest()
# → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

// Java
import java.security.MessageDigest;
MessageDigest md = MessageDigest.getInstance("SHA-256");
byte[] hash = md.digest("hello".getBytes());
// Convert bytes to hex string...

// Go
import "crypto/sha256"
h := sha256.New()
h.Write([]byte("hello"))
hash := fmt.Sprintf("%x", h.Sum(nil))

# Command line (Linux/macOS)
echo -n "hello" | sha256sum
# → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Note the -n flag in the shell example: without it, echo adds a trailing newline to the input, which would change the hash. This is one of the most common sources of hash mismatch when computing hashes manually.

Verifying File Downloads with Hash Comparison

Verifying a downloaded file's integrity is a practical and important use of hash functions. Here is how:

1. Download the file and the publisher's checksum (usually listed on the same download page or in a .sha256 file).
2. Compute the hash of your downloaded file using a hash generator or command-line tool.
3. Compare your computed hash with the published hash character by character. They should match exactly.

On Windows: Get-FileHash filename -Algorithm SHA256 in PowerShell.
On macOS/Linux: shasum -a 256 filename
On Linux: sha256sum filename

Encode and decode the hash values or binary data with the Base64 encoder if your workflow involves Base64-encoded hash digests, which is common in JWT tokens and HTTP digest authentication.

Frequently Asked Questions

Can I reverse a hash to get the original text?

For secure algorithms like SHA-256, reversing a random input is computationally infeasible — there is no known algorithm faster than trying all possible inputs. However, for common inputs like dictionary words, common passwords, and short strings, precomputed rainbow tables exist. If you hash "password123" with SHA-256, an attacker with a rainbow table can look up the hash and immediately find the input. This is why password hashing requires salting and slow hash functions — to make precomputed tables useless and brute force impractical.

Why do hashes change when I add a space?

The avalanche effect means any change to the input — including trailing spaces, newlines, encoding differences (UTF-8 vs UTF-16), or byte-order marks — completely changes the hash. When comparing hashes, both inputs must be byte-for-byte identical. Many hash mismatches in practice are caused by invisible whitespace differences or line ending variations (LF vs CRLF).

Are SHA-256 hashes unique?

Theoretically, collisions are possible because there are more possible inputs than possible 256-bit outputs. In practice, no SHA-256 collision has ever been found, and none is expected to be found in the foreseeable future. The probability of a random collision is approximately 1 in 2¹²⁸ — a number so large it exceeds the number of atoms in the observable universe. SHA-256 is considered collision-resistant against both classical and (with the caveat that quantum computing advances could change this) quantum attacks.

What is the difference between SHA-2 and SHA-3?

SHA-2 (which includes SHA-256, SHA-384, SHA-512) and SHA-3 (Keccak) are both NIST-standardised hash families, but they use completely different internal constructions. SHA-2 uses a Merkle–Damgård structure similar to MD5 and SHA-1. SHA-3 uses a sponge construction, which is architecturally distinct and resistant to the length-extension attacks that affect SHA-2 in certain usage patterns. SHA-3 was standardised in 2015 as an alternative to SHA-2, not a replacement — both remain secure. SHA-256 is far more widely deployed due to legacy and performance reasons.

Should I use MD5 for any security purpose at all?

No. Even for seemingly innocuous security uses, MD5 should not be used — the margin of safety is gone. For any integrity or authenticity purpose where security matters, use SHA-256 or higher. For non-security uses (cache keys, ETags, deduplication, random-looking identifiers), MD5 is fine and still widely used due to its speed and near-universal availability.