Hash Generator
Generate MD5, SHA-1, SHA-256, SHA-512 and HMAC hashes instantly. Hash text live or upload a file.
100% private
Compute MD5, SHA-1, SHA-256, and SHA-512 digests over text or files — the same hex strings you'd get from openssl, hashlib, or the equivalent in any language. Useful for verifying a downloaded file matches a checksum the publisher posted, generating ETags during cache work, and producing deterministic identifiers for content addressing. SHA hashes use the browser's SubtleCrypto so the implementation is the same code the rest of the web platform uses; the input you hash stays on your device.
Input Text
Hash Results
All four algorithms computed simultaneously
MD5128 bit
—
SHA-1160 bit
—
SHA-256256 bit
—
SHA-512512 bit
—
Algorithm Comparison
MD5⚠ Insecure
Checksums, non-security use only
SHA-1⚠ Deprecated
Legacy systems, git commit IDs
SHA-256✓ Secure
Digital signatures, TLS, certificates
SHA-512✓ Most secure
High-security systems, large data
Runs in your browser
Next steps
Base64 Converter
RecommendedEncode or decode Base64 in one click — works with text and files.
JSON Formatter
RecommendedInstantly format, validate, or minify JSON — spot errors in seconds.
UUID Generator
Generate v4 (crypto-random) or v1 (time-based) UUIDs instantly — copy one or generate a batch.
Regex Tester
Write and test regex patterns with real-time match highlighting.
Runs right inside your browser tab. No uploads. Your files stay private.
What Is a Hash Generator?
A cryptographic hash function maps an input of any size to a fixed-length output (the digest), with two critical properties: the same input always produces the same output, and finding two distinct inputs that hash to the same output (a collision) should be computationally infeasible. It's the building block of digital signatures, password storage, integrity checking, and Merkle trees.
This generator implements four standard digests - MD5 (128-bit, RFC 1321), SHA-1 (160-bit, FIPS 180-4), SHA-256 (256-bit), and SHA-512 (512-bit) - plus all four HMAC variants per RFC 2104. The fast SHA family runs through the browser's native Web Crypto API (window.crypto.subtle.digest), which the browser implements in optimized C++ and exposes as a Promise-based interface. MD5 isn't available in Web Crypto by design (it's deprecated for security), so it routes through the crypto-js library, which provides a portable JavaScript implementation.
Why dual implementations? Web Crypto is faster and more trustworthy (constant-time, audited C++) but supports only the modern SHA family. crypto-js is slower (pure JavaScript) but covers MD5, MD4, and HMAC variants on top of MD5. The hybrid here gives you Web Crypto speed for SHA-1/256/512 and crypto-js compatibility for MD5 - the same approach Node.js' crypto module takes internally.
Security state of the art in 2026: MD5 has been broken since 2004 (collisions can be found in seconds on a laptop) - use it only for non-security checksums like cache keys and content-addressable lookups. SHA-1 has been broken since the SHAttered attack in 2017 - GitHub still uses it for commit hashes (because of historical backwards compatibility) but every TLS certificate authority abandoned it in 2017. SHA-256 and SHA-512 remain secure and are the right defaults for any new system. SHA-3 (Keccak) is also secure but isn't in this tool because Web Crypto doesn't support it.
HMAC (Hash-based Message Authentication Code) wraps a hash function with a secret key to produce a value that can't be forged without knowing the key. It's the basis of JWT's HS256 algorithm, AWS request signing (SigV4 uses HMAC-SHA256), webhook signatures from Stripe, GitHub, Slack, and basically every API security scheme that doesn't use full asymmetric cryptography. The construction prepends the key (padded to the block size) twice with different XOR pads, which is what makes it resistant to length-extension attacks that plain hash(key + message) suffers from.
File hashing reads the entire file into an ArrayBuffer with file.arrayBuffer(), then runs all four digests in parallel via Promise.all. For files up to a few hundred MB this is comfortably fast. For multi-gigabyte files the bottleneck is the in-memory buffer - real-world tools (sha256sum, openssl) stream chunks instead. If your file is too big for browser memory, fall back to the OS command-line tools.
Privacy: text inputs and file contents are processed entirely in your tab. Web Crypto runs locally, crypto-js is just JavaScript, and there's no telemetry or upload. The hash you see is the same byte string that openssl dgst -sha256 file.bin or sha256sum file.bin would produce on your machine, so you can use the output to verify downloads without trusting this page.
Common Use Cases
01
Verifying a downloaded ISO
Hash a Linux distribution ISO and compare against the SHA-256 the project publishes to confirm the download wasn't corrupted or tampered with.
02
Generating webhook signatures
Compute the HMAC-SHA256 of a payload with your shared secret to verify or build webhook signatures (Stripe, GitHub, Slack).
03
Cache key derivation
Hash long input strings (URLs, query parameters) to short fixed-length cache keys for an in-memory or Redis cache.
04
Content-addressable storage
Hash a blob to use the digest as its storage key - the same trick git, IPFS, and Docker layer storage all use.
Frequently Asked Questions
MD5 outputs 128 bits, SHA-256 outputs 256 bits. MD5 has been collision-broken since 2004 - given enough compute, anyone can craft two different inputs that hash to the same MD5. SHA-256 has no known practical attacks. For anything where collision resistance matters (signatures, integrity, certificates), use SHA-256.
No - hashing is one-way by design. The only way to find an input that produces a given hash is to try inputs until one matches (preimage attack). For a 256-bit hash, that's 2^256 attempts on average - more than the number of atoms in the observable universe. Hash "cracking" only works for short or low-entropy inputs because the search space is small.
HMAC stands for Hash-based Message Authentication Code (RFC 2104). It combines a secret key with a hash function in a specific way to produce an authenticator that can't be forged without the key. It's used for JWT HS256 signatures, AWS request signing, and almost every webhook signature scheme.
Researchers demonstrated a practical SHA-1 collision in 2017 (the SHAttered attack), producing two different PDFs with the same SHA-1 digest using ~6500 CPU-years of compute. The cost has dropped since. SHA-1 still appears in legacy systems (git commits, old TLS certs) but should never be chosen for new security-critical work.
The Web Crypto spec deliberately excluded MD5 (and SHA-0) because they're cryptographically broken. To keep MD5 available for legitimate non-security uses (checksums, cache keys, ETag generation), this tool falls back to the crypto-js library's portable JavaScript implementation.
No - use a password-hashing function (bcrypt, scrypt, Argon2). Plain SHA-256 is too fast: a GPU can compute billions per second, making brute-force trivial. Password-hashing functions are deliberately slow and memory-hard. See the bcrypt tool for the right approach.
No. Text hashing runs synchronously in your tab. File hashing reads the file into a local ArrayBuffer that exists only in your tab's memory and is freed when garbage-collected. Nothing is sent to a server, so the SHA-256 of a confidential document never leaves your machine.
Almost always a line-ending issue. sha256sum on Linux hashes the file bytes exactly. If you paste "hello" into a text box that adds a trailing newline (or strips a CRLF on Windows), the resulting bytes differ. Drop the file into the file-hash tab to compare against sha256sum output exactly.
Git uses SHA-1, but newer systems (IPFS, Mercurial 5.0+, the SHA-256 transition for git) use SHA-256. For new content-addressed storage, default to SHA-256 - it's collision-resistant and the digest is short enough (64 hex chars) to be practical.
On the bytes. The tool reads file.arrayBuffer() and hashes the raw byte sequence. That means a UTF-8 encoded text file and the same logical content saved as UTF-16 BOM produce different hashes - which is correct, because they are literally different files at the byte level.
Advertisement
What's next?