Hash Generator
Generate MD5, SHA-1, SHA-256, SHA-384, and SHA-512 hashes from text input. Hashes update in real time. Computed in your browser using the Web Crypto API.
Key features
- Supports MD5, SHA-1, SHA-256, SHA-384, SHA-512 algorithms
- Real-time hashing as you type
- Toggle between uppercase and lowercase hex output
- One-click copy for each hash value
Guide
Hashing transforms input data of any size into a fixed-length string of characters. The same input always produces the same hash. Different inputs produce different hashes (with extremely rare exceptions called collisions). Hashing is a one-way function: you cannot reverse a hash to recover the original input. This tool generates MD5, SHA-1, and SHA-256 hashes from text or file input directly in your browser. ## How Hashing Works A hash function takes an input (a string, a file, or any sequence of bytes) and runs it through a mathematical algorithm that produces a fixed-length output called a digest or hash value. MD5 produces a 128-bit (32 hex character) digest. SHA-1 produces a 160-bit (40 hex character) digest. SHA-256 produces a 256-bit (64 hex character) digest. The internal workings involve splitting the input into fixed-size blocks, padding the last block, and processing each block through multiple rounds of mathematical operations (bitwise operations, modular addition, logical functions). The output of each round feeds into the next, creating a cascade effect where every input bit influences the entire output. The key properties of a cryptographic hash function are: Deterministic: the same input always produces the same output. Hashing "hello" with SHA-256 will always produce 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824, on any machine, in any programming language, at any time. Pre-image resistant: given a hash, it is computationally infeasible to find any input that produces it. You cannot reverse-engineer the original data from a SHA-256 hash. The only approach is brute force: trying inputs until one matches. Second pre-image resistant: given an input and its hash, it is computationally infeasible to find a different input that produces the same hash. Collision resistant: it is computationally infeasible to find any two different inputs that produce the same hash. For SHA-256, the probability of a random collision is 1 in 2^128 (the birthday bound), which is about 3.4 x 10^38. To put that in perspective, if every computer on Earth generated a billion hashes per second, it would take longer than the age of the universe to find a collision. Avalanche effect: a tiny change in the input produces a completely different hash. Changing "hello" to "Hello" (capital H) produces an entirely different SHA-256 output: 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969. There is no mathematical relationship between the two outputs that an observer could use to deduce the input change. ## MD5 (Message Digest 5) MD5 produces a 128-bit hash. It was designed in 1991 by Ronald Rivest as an improvement over MD4. MD5 is fast and widely supported across every programming language and operating system, but it is cryptographically broken. Collision attacks were theoretically possible by 2004 (Wang and Yu), and practical chosen-prefix collisions were demonstrated in 2012. This means an attacker can create two different files with the same MD5 hash, which destroys the integrity guarantee. In 2008, researchers used an MD5 collision attack to create a rogue SSL certificate that appeared to be signed by a legitimate certificate authority. This real-world exploit demonstrated that MD5's weaknesses have practical security consequences. Do not use MD5 for security purposes: digital signatures, certificate verification, password hashing, message authentication, or any scenario where an adversary might craft malicious inputs. MD5 is still acceptable for non-security purposes: verifying file integrity during transfers (did the download complete without corruption due to network errors?), generating cache keys, creating deterministic identifiers from content, deduplication checksums, and ETags for HTTP caching. Many systems still use MD5 for these purposes because of its speed, universality, and 32-character output that fits neatly in database columns and filenames. Example: echo -n "hello" | md5sum produces 5d41402abc4b2a76b9719d911017c592. ## SHA-1 (Secure Hash Algorithm 1) SHA-1 produces a 160-bit hash. Designed by the NSA and published by NIST in 1995. SHA-1 served as the standard cryptographic hash for over a decade, but it is now considered cryptographically broken. Theoretical attacks were published in 2005 (Wang, Yin, Yu), and Google demonstrated a practical collision attack called SHAttered in 2017, producing two different PDF files with identical SHA-1 hashes. The attack cost approximately $110,000 in cloud computing resources at the time, making it accessible to well-funded adversaries. Git historically used SHA-1 for commit, tree, blob, and tag identifiers. Every commit hash you see in git log is a SHA-1 hash. Git is transitioning to SHA-256 (behind the extensions.objectFormat config), but SHA-1 remains the default in most installations. For Git's use case (identifying content in a trusted environment), SHA-1 is acceptable because the attack scenario (someone deliberately crafting a collision to replace a file in a repository) is different from general cryptographic use and requires significant computational resources. Do not use SHA-1 for security purposes. All major certificate authorities and web browsers deprecated SHA-1 certificates in 2017. Chrome, Firefox, Edge, and Safari reject SHA-1 signed certificates. SHA-1 is acceptable for content-addressable storage, cache keys, non-security checksums, and backward compatibility with systems that require SHA-1. Many APIs and protocols still reference SHA-1 for legacy reasons. Example: echo -n "hello" | sha1sum produces aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d. ## SHA-256 (Secure Hash Algorithm 256) SHA-256 is part of the SHA-2 family (which also includes SHA-224, SHA-384, and SHA-512), producing a 256-bit hash. Designed by the NSA and published by NIST in 2001. No practical attacks against SHA-256 are known. The best theoretical attack reduces the collision resistance from 2^128 to 2^127.5, which is negligibly weaker and still far beyond any achievable computation. SHA-256 is the current standard for cryptographic hashing in most applications: - TLS/SSL certificates use SHA-256 for certificate signing - Code signing (Windows Authenticode, Apple notarization, Android APK) uses SHA-256 - Blockchain: Bitcoin uses double SHA-256 (SHA-256 applied twice) for proof-of-work mining and transaction verification - Digital signatures (ECDSA, RSA-PSS) hash the message with SHA-256 before signing - HMAC-SHA256 is the standard for API request signing (AWS Signature V4, Stripe, GitHub webhooks) - Docker image digests use SHA-256 - Subresource Integrity (SRI) in browsers uses SHA-256 or SHA-384 to verify CDN-hosted scripts - Package managers (npm, pip, cargo) verify download integrity with SHA-256 SHA-256 is slower than MD5 and SHA-1 but the difference is negligible for typical use cases. For hashing a single string or a file under 100MB, the speed difference is imperceptible. On modern CPUs with SHA-NI hardware acceleration (Intel since Goldmont, AMD since Zen), SHA-256 throughput approaches or exceeds MD5. Example: echo -n "hello" | sha256sum produces 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. ## Use Cases for Hash Generation File integrity verification: Download a file and compute its SHA-256 hash. Compare it with the hash published by the source (usually listed on the download page). If they match, the file was not corrupted or tampered with during transfer. This is standard practice for downloading operating system ISOs, security tools, and cryptocurrency wallets. Example: the Python downloads page lists SHA-256 hashes for every installer. Password storage (with proper hashing): Never store passwords in plain text. Hash them before storing. However, general-purpose hash functions (MD5, SHA-1, SHA-256) are not suitable for direct password hashing because they are too fast. An attacker with a modern GPU can compute billions of SHA-256 hashes per second. Use dedicated password hashing functions like bcrypt (cost factor 12+), scrypt, or Argon2id that are deliberately slow and memory-hard. These functions internally use cryptographic hashes but add iterations and salt to make brute-force attacks impractical. This tool is for general hashing, not for password storage. Data deduplication: Hash file contents and compare hashes to find duplicates. Two files with the same SHA-256 hash are identical with virtual certainty (the chance of a false positive is 1 in 2^128). This is more efficient than comparing file contents byte by byte, especially when checking thousands of files across a distributed system. Cloud storage providers like Dropbox use content hashing for deduplication. Content addressing: Use the hash of content as its identifier. Git does this for every object (blob, tree, commit). IPFS uses content hashes as addresses. Docker uses content-addressable storage for image layers. CDNs use content hashes for cache keys (if the hash changes, the content changed, so the cache is invalidated). This ensures that the identifier changes whenever the content changes, providing automatic cache busting and integrity verification. Checksum validation: When transferring data between systems, compute a hash before sending and after receiving. If the hashes match, the transfer was successful. This catches bit flips, truncation, and encoding errors that silent data corruption can cause. Network protocols like TCP have their own checksums, but application-level checksums provide defense in depth. Digital signatures: Hash the document first, then sign the hash with a private key. Signing a 256-bit hash is much faster than signing a multi-megabyte document directly. The signature verifier independently hashes the document and checks that the signed hash matches the computed hash. API request signing: AWS Signature Version 4 computes HMAC-SHA256 of the request components (method, path, headers, body) with a secret key. GitHub webhook payloads include an X-Hub-Signature-256 header containing HMAC-SHA256 of the body. Stripe uses a similar scheme. The receiving server recomputes the HMAC and rejects requests where the signature does not match. Subresource Integrity (SRI): When loading JavaScript or CSS from a CDN, add an integrity attribute: <script src="https://cdn.example.com/lib.js" integrity="sha256-abc123..." crossorigin="anonymous"></script>. The browser computes the SHA-256 hash of the downloaded file and refuses to execute it if the hash does not match. This prevents CDN compromises from injecting malicious code. ## Using the Tool For text hashing: type or paste your text into the input field. The tool computes MD5, SHA-1, and SHA-256 hashes simultaneously and displays all three. Copy whichever hash you need. The computation is instant for typical text inputs. For file hashing: drop a file into the tool or use the file selector. It reads the file in your browser using the File API and computes the hashes using the SubtleCrypto API (for SHA-1 and SHA-256) or a JavaScript implementation (for MD5). The file is not uploaded to any server. This is useful for verifying downloaded files against published checksums without installing command-line tools. The hashes are displayed as hexadecimal strings (each byte represented as two hex digits, lowercase). This is the standard representation used by sha256sum, hashlib, and most tools. Some systems use Base64-encoded hashes (shorter but less common) or uppercase hex. ## Common Mistakes Mistake 1: Using MD5 or SHA-1 for security. These algorithms are broken for cryptographic purposes. Use SHA-256 or SHA-3 for any security-related hashing (signatures, HMAC, integrity in adversarial contexts). Mistake 2: Hashing passwords with SHA-256 directly. While SHA-256 is cryptographically strong, it is too fast for password hashing. A single GPU can compute over 20 billion SHA-256 hashes per second. With a 256-byte hash, an attacker can brute-force all 8-character passwords in about an hour. Use bcrypt (cost factor 12+), scrypt, or Argon2id. These functions deliberately consume time and memory, making brute-force attacks thousands of times slower. Mistake 3: Forgetting that hashing is encoding-sensitive. The string "hello" in UTF-8 and "hello" in UTF-16 produce different hashes because the byte representations differ. The string "hello" with a BOM produces a different hash than without. Always ensure consistent encoding across systems. This tool uses UTF-8, which is the standard for web applications. Mistake 4: Including a trailing newline. echo "hello" (without -n) in bash appends a newline character (0x0A), producing a different hash than echo -n "hello". If your hash does not match the expected value, check for trailing whitespace, newline characters, or carriage returns. Windows line endings (\r\ ) also produce different hashes than Unix line endings (\ ). Mistake 5: Confusing hash algorithms. SHA-256 and SHA-2 are often used interchangeably, but SHA-2 is a family (SHA-224, SHA-256, SHA-384, SHA-512). SHA-256 is a specific member. SHA-3 is a completely different algorithm (Keccak) with the same output sizes. Make sure you know which algorithm a system expects. ## Advanced Tips When verifying file downloads, compute the hash immediately after downloading, before opening, extracting, or executing the file. This prevents a scenario where malware modifies the file after download but before verification. HMAC (Hash-based Message Authentication Code) combines a hash function with a secret key: HMAC(key, message) = hash((key XOR opad) || hash((key XOR ipad) || message)). HMAC-SHA256 is used for API authentication, webhook verification, and message integrity. Unlike a plain hash, HMAC proves that the sender knows the secret key. Never compute a MAC by simple concatenation (hash(key + message)), as this is vulnerable to length extension attacks. Hash chains are sequences where each value is the hash of the previous one: H1 = hash(seed), H2 = hash(H1), H3 = hash(H2). They are used in one-time password systems (S/KEY), blockchain, and commitment schemes (reveal the hash first, reveal the pre-image later to prove commitment). For comparing large datasets, compute hashes of segments rather than the entire dataset. Split two files into 1MB blocks and hash each block. Compare the block hashes to identify exactly which blocks differ. This is how rsync, ZFS scrubbing, and cloud backup systems detect changes efficiently. Salt is a random value added to input before hashing. For password hashing, always use a unique random salt per password. Store the salt alongside the hash. Without salt, identical passwords produce identical hashes, enabling rainbow table attacks (precomputed hash-to-password mappings). With per-password salt, every hash is unique even for identical passwords. Proper password hashing functions (bcrypt, Argon2) handle salting automatically. Merkle trees (hash trees) compute hashes of individual data blocks, then hash pairs of block hashes together, continuing recursively until a single root hash remains. This structure allows efficient verification of any individual block by providing a short proof path (log2(n) hashes) rather than re-hashing the entire dataset. Git, blockchain, certificate transparency, and IPFS all use Merkle trees. ## SHA-3 and Future Hash Functions SHA-3 (Keccak) was selected by NIST in 2012 as the next-generation hash standard. It uses a completely different internal structure (sponge construction) compared to SHA-2's Merkle-Damgard construction. SHA-3 is not a replacement for SHA-2 (SHA-256 remains unbroken) but provides an alternative in case SHA-2 is ever compromised. SHA-3-256 produces a 256-bit hash like SHA-256 but with different internal operations. BLAKE2 and BLAKE3 are modern hash functions that are faster than MD5 while providing SHA-3-level security. BLAKE3 is parallelizable and can hash data at over 1 GB/s on a single core. It is gaining adoption in file integrity tools, build systems, and content-addressable storage. For most development work in 2026, SHA-256 remains the standard choice. Use SHA-3 when required by a specification or regulation. Use BLAKE3 when speed is critical and your ecosystem supports it (Rust's cargo uses BLAKE3 for checksums). ## Hash Functions in Web Development Subresource Integrity (SRI) uses SHA-256, SHA-384, or SHA-512 hashes to verify that files loaded from CDNs have not been tampered with. Generate the hash with: openssl dgst -sha384 -binary library.js | openssl base64 -A. Include it in the script tag: <script src="https://cdn.example.com/lib.js" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC" crossorigin="anonymous"></script>. If the CDN serves a modified file (due to compromise or accident), the browser refuses to execute it. Content Security Policy (CSP) can use hashes to allow specific inline scripts. Instead of using unsafe-inline (which defeats CSP), compute the SHA-256 hash of your inline script and add it to the policy: Content-Security-Policy: script-src 'sha256-abc123...'. Only inline scripts matching the hash will execute. ETag headers in HTTP caching can use content hashes. When a server returns ETag: "sha256:2cf24dba...\
Frequently asked questions
What is a hash?
A hash is a fixed-size string generated from input text. The same input always produces the same hash, but you cannot reverse it.
Which hash algorithm should I use?
SHA-256 is the most common for security. MD5 is fast but not secure. SHA-512 offers the highest security.
