Hash Generator Free Online
Free online hash generator. Generate MD5, SHA-1, SHA-256 and SHA-512 hashes from any text string instantly in your browser.
Cryptographic hash functions are fundamental to modern computer security and data integrity verification. They convert any input - whether a single character, a password, an entire file, or a database record - into a fixed-length string of hexadecimal characters called a hash, digest, or checksum. This free hash generator supports MD5, SHA-1, SHA-256, and SHA-512 algorithms, computing all four hashes simultaneously for any input you provide, entirely within your browser using the Web Crypto API.
How to Use the Hash Generator
Type or paste your input text
Enter the text string you want to hash in the input field. This can be a password, a message to verify, a file checksum you want to compute, an API key, or any other string. The hashes update automatically as you type - you do not need to click any button.
Review all four hash values
All four hash algorithms (MD5, SHA-1, SHA-256, SHA-512) are computed simultaneously and displayed below the input. Compare the lengths: MD5 produces 32 hex characters (128 bits), SHA-1 produces 40 characters (160 bits), SHA-256 produces 64 characters (256 bits), and SHA-512 produces 128 characters (512 bits).
Copy the hash you need
Click the Copy button next to your preferred algorithm to copy just that hash value to your clipboard. Use it for verification, comparison, storage, or any other security or data integrity purpose.
What Are Cryptographic Hash Functions?
A cryptographic hash function takes an input of any length and produces a fixed-length output (the hash) with several critical properties. First, determinism: the same input always produces the exact same hash - "hello" will always hash to the same SHA-256 value. Second, avalanche effect: even a tiny change to the input produces a completely different hash - changing one character changes roughly half of all the bits in the output. Third, one-way: it is computationally infeasible to reverse the hash to recover the original input. Fourth, collision resistance: it is computationally infeasible to find two different inputs that produce the same hash.
These properties make hash functions essential for password storage, file integrity verification, digital signatures, and many other security applications.
Choosing the Right Hash Algorithm
MD5 (128-bit, 32 hex characters) - one of the oldest and most widely recognised hash algorithms, developed in 1991. MD5 is no longer considered cryptographically secure for security purposes - it is vulnerable to collision attacks, meaning two different inputs can produce the same MD5 hash. However, MD5 is still widely used for non-security purposes like file integrity checks where collision resistance is not a concern, and for generating unique identifiers from content.
SHA-1 (160-bit, 40 hex characters) - an older algorithm from 1995. SHA-1 has also been compromised - practical collision attacks were demonstrated in 2017 by Google's SHAttered project. SHA-1 should not be used for security-critical applications including digital certificates, TLS, or password hashing. It is still used in some legacy systems and non-security contexts like Git commit identifiers.
SHA-256 (256-bit, 64 hex characters) - the current gold standard for most security applications. SHA-256 is part of the SHA-2 family and has no known practical vulnerabilities. It is used in TLS/SSL certificates, Bitcoin blockchain mining, code signing, JWT signatures, and most modern security protocols. Use SHA-256 for any security-sensitive application.
SHA-512 (512-bit, 128 hex characters) - provides a larger hash output than SHA-256. SHA-512 is sometimes preferred for very high-security applications where additional margin against future computing advances is desired. On 64-bit systems, SHA-512 can actually be faster than SHA-256 due to the way processors handle 64-bit operations. Both SHA-256 and SHA-512 offer more than adequate security for any current application.
Common Uses of Cryptographic Hashing
Password storage - websites should never store passwords in plain text. Instead, they store a hash of the password. When you log in, the submitted password is hashed and compared to the stored hash. Note: For password hashing specifically, general-purpose hash functions like SHA-256 should be combined with a salt (random value) to prevent rainbow table attacks. Dedicated password hashing functions like bcrypt, Argon2, or PBKDF2 are preferred in production systems.
File integrity verification - when you download software or files from the internet, the provider often publishes the SHA-256 or MD5 hash of the file. You can hash the downloaded file and compare your computed hash to the published one - if they match, the file was not tampered with during download. Many Linux distributions and open source projects publish SHA-256 checksums for their downloads.
Digital signatures - hash functions are integral to digital signatures. Rather than signing an entire document (which could be very large), you hash the document to produce a short digest and then sign just the hash. The recipient hashes the received document and verifies that the signature matches - if it does, the document has not been altered.
Content deduplication - databases and storage systems use hashes to detect duplicate content. By hashing each piece of content and comparing hashes, the system can instantly identify duplicates without comparing the full content byte-by-byte.
Why Password Hashing Requires Salting
When hashing passwords for storage, using a general-purpose hash function alone (SHA-256, MD5, etc.) is not sufficient for security. The problem is rainbow tables and precomputed hash databases.
Rainbow tables: Attackers precompute the hashes of millions of common passwords and store them in a massive lookup table. When they obtain a database of hashed passwords, they can instantly look up each hash to see if it matches a known password. For example, the SHA-256 hash of "password123" is always 0b14d501a594442a01c6859541bcb3e8164d183a32937b851835442f69d5c94e - this is in every rainbow table.
The salt solution: A salt is a random value (typically 16-32 bytes) generated uniquely for each password. Before hashing, the salt is concatenated with the password, so you are actually hashing "randomsalt123password123" instead of just "password123". The salt is stored alongside the hash in the database - it does not need to be secret. Because each password has a different random salt, identical passwords produce different hashes, and rainbow tables become useless (they would need to include every possible password combined with every possible salt, which is computationally impossible).
Example workflow:
// Account creation
1. User submits password: "MySecurePassword"
2. Generate random salt: "a3f8d9c2b1e5"
3. Combine: "a3f8d9c2b1e5MySecurePassword"
4. Hash with SHA-256: produces hash H
5. Store in database: {email, salt: "a3f8d9c2b1e5", hash: H}
// Login verification
1. User submits password: "MySecurePassword"
2. Look up user's stored salt: "a3f8d9c2b1e5"
3. Combine: "a3f8d9c2b1e5MySecurePassword"
4. Hash with SHA-256: produces hash H2
5. Compare H2 to stored hash H - if equal, password is correct
Modern recommendation: Do not implement your own salted hashing. Use a dedicated password hashing function like bcrypt, Argon2, or PBKDF2, which incorporate salting automatically and include additional protections (iteration counts, memory hardness) to slow down brute-force attacks. These functions are specifically designed to make password cracking expensive even with powerful hardware.
Hash Collisions - Why They Matter and When They Do Not
A collision occurs when two different inputs produce the same hash output. Cryptographic hash functions are designed to make collisions computationally infeasible, but as computing power increases and weaknesses are discovered, older algorithms become vulnerable.
MD5 collisions: In 2004, researchers demonstrated MD5 collisions - they could generate two completely different files that produce the same MD5 hash. This breaks MD5 for security purposes. An attacker could create a malicious file with the same MD5 hash as a legitimate file, bypassing integrity checks.
SHA-1 collisions: In 2017, Google's SHAttered project created two different PDF files with the same SHA-1 hash, proving practical collision attacks are feasible. This is why SHA-1 is deprecated for certificates, signatures, and other security uses.
When collisions do not matter: For non-adversarial uses - like generating unique IDs for content, distributing database load across shards, or checksumming files for accidental corruption detection - MD5 and SHA-1 are still fine. The risk is when an attacker can deliberately craft a collision.
SHA-256 and SHA-512 status: No practical collision attacks exist for SHA-256 or SHA-512. They remain secure for all purposes. Theoretical birthday attacks require 2^128 operations for SHA-256 and 2^256 operations for SHA-512 - both far beyond current and foreseeable computing capabilities.
How Hashing Is Used in Blockchain and Cryptocurrency
Blockchain technology relies fundamentally on cryptographic hashing for security and immutability:
Bitcoin mining - proof of work: Bitcoin miners compete to find a nonce (a random number) that when hashed together with the block data produces a hash with a specific number of leading zeros. For example, a valid Bitcoin block hash might need to start with 19 leading zeros (hexadecimal). Because hash functions are unpredictable, the only way to find such a hash is trial and error - miners hash billions of different nonce values per second until one produces the required result. This computational work is what secures the blockchain.
Block chaining: Each block in a blockchain contains the hash of the previous block. This creates an immutable chain - if anyone tries to alter a past block, its hash changes, which breaks the link to the next block. Fixing that would require recalculating the hash for every subsequent block, which is computationally infeasible for long chains.
Merkle trees: Blockchains and distributed systems use Merkle trees (hash trees) for efficient verification. All transactions in a block are hashed in a tree structure, with pairs of hashes being hashed together until a single root hash remains. This allows anyone to verify that a specific transaction is in the block by checking only log(n) hashes rather than downloading the entire block.
Address generation: Cryptocurrency addresses are derived by hashing public keys (often multiple rounds of hashing with SHA-256 and RIPEMD-160). This makes addresses shorter and adds an extra layer of security.
HMAC - Hash-Based Message Authentication Codes
HMAC is a construction for creating a message authentication code using a cryptographic hash function and a secret key. It provides both integrity (the message has not been tampered with) and authenticity (the message came from someone who knows the secret key).
How HMAC works: HMAC(key, message) = H((key ⊕ opad) || H((key ⊕ ipad) || message)), where H is the hash function (like SHA-256), ⊕ is XOR, || is concatenation, and ipad and opad are padding constants. The details are complex, but the result is that you cannot produce a valid HMAC without knowing the secret key.
Common uses of HMAC:
API request signing: Many APIs (AWS, Stripe, PayPal) require HMAC-SHA256 signatures. The client signs the request with a secret key, and the server verifies the signature using the same key. This prevents tampering and proves the request came from an authorised client.
JWT signatures: JWTs using HS256 algorithm are signed with HMAC-SHA256. The payload and header are hashed with a secret key to create the signature.
Cookie integrity: Web frameworks often HMAC-sign session cookies so they can detect if a user tampered with the cookie content.
HMAC vs plain hashing: A plain hash provides integrity only - you can verify the data has not changed. HMAC provides integrity and authenticity - you can verify the data came from someone who has the secret key. HMAC is a keyed hash, while basic hashing is keyless.