Hash Generator
Generate SHA-256, SHA-384, SHA-512, or SHA-1 hashes from text or files. 100% client-side via Web Crypto API.
Last reviewed: April 2026New to this tool? Click here for instructions
Quick Answer
A hash function turns any input into a fixed-length string (a digest) that changes completely if the input changes even slightly and cannot be reversed to recover the input. This tool generates MD5, SHA-1, SHA-256, and other hashes from your text. Paste text above to hash it. Note that MD5 and SHA-1 are outdated for security. Everything runs in your browser.
How to Use the Hash Generator
To use the Hash Generator, simply enter your text in the input area on the left (or top on mobile), or click "Hash File" to select a file from your device. Choose a hash algorithm - SHA-256 (default), SHA-384, SHA-512, or SHA-1. View the hash - the hexadecimal hash digest appears instantly on the right. Copy or download - use the buttons above the output to copy the hash to your clipboard or download it as a text file.
When to Use the Tool in Real Workflows
Use the Hash Generator when you need to ensure data integrity and security. It's particularly useful for verifying file downloads, ensuring data has not been tampered with, and for compliance with security standards.
How It Works
This hash generator uses the Web Crypto API built into modern browsers to compute cryptographic hash digests. When you enter text or select a file, the tool converts the input into bytes, passes them through the selected hashing algorithm, and displays the resulting fixed-length hexadecimal string. Everything happens locally in your browser - no data is ever transmitted to a server.
Tips, Edge Cases, or Limitations
Ensure your browser supports the Web Crypto API for optimal performance. The tool does not support MD5 due to its cryptographic weaknesses. Always verify the integrity of the data you are hashing to ensure the results are accurate.
Frequently Asked Questions
Compute MD5, SHA-1, SHA-256, SHA-384, or SHA-512 digests of arbitrary text or files entirely in your browser. Every byte you paste or drop into this page stays on your machine — the Web Crypto API runs the algorithm locally and returns hex and Base64 output for copy, verification, or download.
What This Tool Does
This tool computes cryptographic hash digests of text strings or files using the browser-native Web Crypto API — specifically the SubtleCrypto.digest() method exposed on every modern browser since Chrome 37, Firefox 34, and Safari 11. The supported algorithm set covers SHA-256, SHA-384, SHA-512, SHA-1, and MD5: the SHA-2 family (the first three) is the modern default and remains cryptographically sound; SHA-1 is included for legacy compatibility (Git object IDs, older signing systems); MD5 is provided strictly for non-security uses such as cache-busting, content-addressed deduplication, and verifying file integrity against a published checksum on a trusted source.
Output is rendered in two encodings simultaneously: hex (the conventional lowercase hexadecimal representation, what you'll see in Git, in shasum output, and in most documented checksums) and Base64 (used by Subresource Integrity attributes, JWT signatures, and many cloud-storage ETag headers). One-click copy buttons sit beside each encoding, and the entire output can be downloaded as a plain text file. Every byte of input and every byte of output remains client-side throughout — there is no upload, no network round trip, and no server-side state. This matters for sensitive content (API keys, contract drafts, internal-only documents) and for compliance contexts where data residency requirements forbid sending content off-device. 🔒
How to Use It
The interface mirrors the way you actually compute hashes in a terminal: provide input, pick an algorithm, read the digest. The four steps below cover both text and file inputs.
1. Provide Input — Text or File
Type or paste text directly into the input pane on the left (top on mobile). For files, click Hash File and select any file from your device — images, archives, executables, and source code all work. The file is read into an ArrayBuffer via the FileReader API; nothing is uploaded. There is no practical upper bound on file size beyond your browser's available memory, but very large files (several gigabytes) may take a moment to read before hashing begins.
2. Pick an Algorithm
The chip row beneath the input selects between SHA-256 (default), SHA-384, SHA-512, and SHA-1. SHA-256 is the right default for almost everything: file integrity verification, content addressing, building HMAC tags, or generating commit-style identifiers. Use SHA-512 when your downstream system explicitly requires it (some PKI and document-signing standards do), or when you want the wider 256-bit collision-resistance margin. SHA-1 should be selected only for legacy interoperation — for example, recomputing a Git blob hash for a repository that has not migrated to SHA-256 yet.
3. Read the Digest in Hex and Base64
The output pane on the right shows the digest in lowercase hexadecimal as soon as you change the input or switch algorithms. Live processing is debounced at 150 ms so typing feels instant without recomputing the hash on every keystroke. SHA-256 produces 64 hex characters; SHA-384 produces 96; SHA-512 produces 128; SHA-1 produces 40. The Base64 representation appears beneath the hex output for the same digest bytes — Base64 is shorter (44 characters for SHA-256) and is the encoding used by HTTPS Subresource Integrity attributes and JWT signature parts.
4. Copy or Download
The Copy button copies the hex digest to your clipboard. Download saves the digest as a plain .txt file named after the source input — useful when you want to attach a checksum alongside a file you're publishing. For complete reproducibility, the status bar reports which algorithm produced the digest, the byte length of the input, and whether the source was text or a file by name.
Worked Example: Hash "hello" with SHA-256, MD5, and SHA-1
Hashing the five-byte ASCII string hello with three different algorithms produces three completely unrelated digests. This is the most direct way to observe how a hash function behaves and why the avalanche effect matters.
- Enter the input. Type
hello(lowercase, no quotes, no trailing newline) into the input pane. The byte sequence is68 65 6c 6c 6f— five bytes total. - Compute SHA-256. With SHA-256 selected the output reads
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824— 64 hex characters, 256 bits. - Switch to MD5. The same five-byte input produces
5d41402abc4b2a76b9719d911017c592— 32 hex characters, 128 bits. - Switch to SHA-1. The output becomes
aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d— 40 hex characters, 160 bits. - Test the avalanche effect. Change the input by one byte — capitalize the first letter to produce
Hello. The new SHA-256 digest is185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969. Compare the two digests character by character: roughly 75% of the hex characters differ, even though the input changed by exactly one bit in one byte.
Expected output: three unrelated digests for the same input depending on algorithm selection, and a near-complete reshuffle of the SHA-256 digest after a single-bit input change.
| Algorithm | Digest Bits | Hex Characters | Output for "hello" |
|---|---|---|---|
| MD5 | 128 | 32 | 5d41402abc4b2a76b9719d911017c592 |
| SHA-1 | 160 | 40 | aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d |
| SHA-256 | 256 | 64 | 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 |
The avalanche effect — a roughly 50% bit-flip in the output for a one-bit input change — is what makes a hash function cryptographically useful. If small input changes produced small output changes, an attacker observing many digests of related inputs could reconstruct the inputs themselves. With proper avalanche, the digest of hello and the digest of Hello are indistinguishable from random strings of the same length, leaking nothing about how the inputs are related.
Common Use Cases: File Integrity, Content Addressing, and Code Signing
File Integrity and Download Verification
The most common real-world use of cryptographic hashes is download verification. A Linux distribution publishes both the ISO image and an SHA-256 digest of that image; after downloading, you compute the digest locally and compare it to the published value. A match proves two things at once: the file you downloaded is byte-identical to the file the publisher signed, and the file was not silently modified by a CDN edge node, an ISP, or a man-in-the-middle attacker. Major package managers (apt, dnf, npm, pip, cargo) all build the same primitive into their installation pipelines — every package fetch is implicitly hash-verified before extraction.
Git's Content-Addressed Storage and the SHA-1 to SHA-256 Migration
Git is the most widely deployed content-addressed storage system in the world: every blob (file content), tree (directory listing), commit, and tag is identified by the hash of its serialized representation. When Linus Torvalds designed Git in 2005 he chose SHA-1; after the SHAttered collision attack in 2017, the Git project began migrating to SHA-256. New repositories can opt in via git init --object-format=sha256, and interoperability work between SHA-1 and SHA-256 repositories continues. The migration is gradual because the entire ecosystem — GitHub, GitLab, every CI provider, every Git client — must support both formats during the transition window.
Why You Must NOT Use These for Password Storage
This deserves a section of its own because the wrong choice creates a class of vulnerability that is both common and severe. SHA-256 is the wrong tool for password storage. Its design goal is speed — a modern GPU computes several billion SHA-256 hashes per second — and speed is precisely the property an attacker needs when brute-forcing a leaked database. The right tools are deliberately slow Key Derivation Functions: Argon2id (OWASP's current recommendation), scrypt, or bcrypt. These apply per-password salting to defeat rainbow tables and expose tunable work factors (memory, iterations, parallelism) that scale the cost as hardware improves. Use the Password Generator to create strong passwords, then store them via a real KDF — never via a bare SHA-256 hash.
Content-Addressed Storage (IPFS) and Deduplication
InterPlanetary File System (IPFS) addresses every file by its cryptographic hash — its Content Identifier (CID). When you upload a file to IPFS, the CID is computed from the file's bytes (using SHA-256 by default, encoded as a multihash). Anyone with that CID can retrieve the file from any node hosting it, and the integrity check is implicit: if the retrieved bytes don't hash back to the same CID, the content is rejected. The same principle drives storage-level deduplication in backup systems and object stores like ZFS, restic, and S3-compatible storage with content-addressing enabled.
Code Signing and Certificate Authorities
When you install signed software — a Windows MSI package, a macOS app from a developer certificate, a signed JAR — the OS verifies the signature by computing the hash of the binary's contents and comparing it against the signed hash inside the certificate. Code-signing certificates rely on SHA-256 (and increasingly SHA-384) for the underlying digest; SHA-1 was deprecated by Microsoft Authenticode in 2016 and by every major CA shortly after. The hash function's collision resistance is the foundational guarantee — if an attacker could craft two binaries with the same SHA-256 hash, code signing would offer no security.
Edge Cases and Limitations: What Hashes Are Not
Cryptographic hashes are a remarkable primitive but they are routinely misused. The points below cover the most common misunderstandings and the contexts where they break real systems.
MD5 is fully broken — never use it for security. Practical collision attacks against MD5 have been public since 2004 and trivially fast since 2008; a researcher named Marc Stevens demonstrated a chosen-prefix MD5 collision against the Flame malware's signing infrastructure in 2012. MD5 remains acceptable for non-security uses (cache-busting fingerprints, content-addressed deduplication where collision attacks are not in the threat model) but must not appear in any signature, certificate, password hash, or integrity check where an adversary could craft the input.
SHA-1 is broken in the same way, just more slowly. The SHAttered attack (Google + CWI Amsterdam, 2017) produced two different PDFs with identical SHA-1 digests at a computational cost of roughly 110 GPU-years — feasible for a determined attacker today. NIST disallowed SHA-1 for digital signatures in 2013, and every browser, CA, and OS vendor has migrated. SHA-1 may persist in legacy contexts (Git's default object format, older Subversion repositories, deprecated TLS deployments) but should never be selected for new designs.
SHA-256 is still strong. No known cryptographic weakness compromises the SHA-2 family. Quantum computers, if they ever scale, would reduce SHA-256's preimage resistance from 2^256 to 2^128 via Grover's algorithm — still vastly out of reach. The conservative migration path is SHA-3 or SHA-256 with longer digests (SHA-384, SHA-512) for new long-lived signatures.
Hashes are not encryption. A hash function is one-way; an encryption function is reversible with the correct key. You cannot "decrypt a hash" because there is nothing to decrypt — the hash is a digest, not a transformation. The only way to recover the original input from a hash is to guess it and check. This is why password hashes leak nothing about the password's length, structure, or character set when implemented correctly.
Preimage resistance vs. collision resistance. Three security properties define a cryptographic hash. Preimage resistance: given a hash h, you cannot find any input x such that hash(x) = h. Second preimage resistance: given input x, you cannot find a different input y such that hash(y) = hash(x). Collision resistance: you cannot find any pair (x, y) with x ≠ y and hash(x) = hash(y). SHAttered broke SHA-1's collision resistance; MD5 has been fully broken on collision and chosen-prefix collision. SHA-256's properties remain intact.
Salting prevents rainbow tables, but does not replace a slow KDF. A salt is a per-password random value concatenated with the password before hashing — it ensures two users with the same password produce different hashes, defeating precomputed rainbow tables. But salting a fast hash (SHA-256) still allows GPU brute force at billions of hashes per second. The proper construction is salt + slow KDF + tunable work factor, exactly what Argon2id, scrypt, and bcrypt provide.
HMAC is the right tool for keyed integrity. If you need to verify both integrity and origin — "this message was generated by someone who holds the shared secret" — use HMAC, not a plain hash. HMAC-SHA256 appears in TLS, AWS request signing, JWT HS256 tokens, and webhook verification across every API platform. Naively concatenating a key and message before hashing (hash(key || message)) is vulnerable to length-extension attacks against Merkle–Damgård hashes; HMAC's two-keyed-pass construction prevents that.
Hash-then-encrypt vs. encrypt-then-hash (MAC ordering). When combining encryption and a MAC, the canonical correct order is encrypt-then-MAC: encrypt the plaintext, then compute the MAC over the ciphertext. MAC-then-encrypt and encrypt-and-MAC have both been the root cause of major real-world vulnerabilities (Padding Oracle attacks, Lucky 13 against TLS-CBC). Authenticated encryption modes like AES-GCM and ChaCha20-Poly1305 wrap encrypt-then-MAC into a single primitive and are the modern default.
Behind the Scenes: Merkle–Damgård, Sponge, and Web Crypto
Merkle–Damgård Construction (MD5, SHA-1, SHA-2)
MD5, SHA-1, and the SHA-2 family (SHA-256, SHA-384, SHA-512) all share an internal structure called the Merkle–Damgård construction, introduced independently by Ralph Merkle and Ivan Damgård in 1989. The input message is padded to a multiple of the block size, then processed block-by-block through a fixed compression function. Each compression step takes the running internal state and the next block, and produces a new internal state. After the final block, the state is output as the digest. This design is elegant — it reduces hash design to compression-function design — but it inherits a structural weakness: the length-extension attack. Given hash(secret || message) and the length of the prefix, an attacker can compute hash(secret || message || padding || extension) without ever knowing the secret. HMAC's two-pass construction defends against this; bare Merkle–Damgård hashes do not.
Sponge Construction (SHA-3 / Keccak)
SHA-3 (standardized by NIST in 2015 after the Keccak algorithm won the SHA-3 competition) uses a fundamentally different internal structure called the sponge construction. The state is a large fixed-size buffer (1600 bits for SHA-3); input is absorbed into the state via XOR and a permutation, and output is squeezed out the same way. The sponge structure is naturally resistant to length-extension attacks — there is no concept of "feeding the digest back as new state" because the output bits are squeezed from a portion of the state that the absorption step cannot directly reach. SHA-3 also enables variable-length output via SHAKE-128 and SHAKE-256 (extendable-output functions, or XOFs) without changing the underlying primitive.
The Web Crypto API and SubtleCrypto.digest()
This tool calls crypto.subtle.digest(algorithm, data), the W3C Web Cryptography API entry point for hash computation. The browser hands the call off to a native implementation — typically the OS-level crypto provider (BoringSSL on Chrome, NSS on Firefox, CommonCrypto on Safari) — which is hardware-accelerated where the CPU exposes SHA extensions (Intel SHA-NI, ARMv8 Crypto Extensions). The returned Promise<ArrayBuffer> resolves with the raw digest bytes; the tool then converts them to hex by walking the byte array and emitting two hex characters per byte, and to Base64 via the browser's built-in btoa after a binary-string conversion. The entire pipeline runs in a single tight loop and completes in microseconds for typical inputs.
Why SHA-3 Is Structurally Different
SHA-3 is not a faster or stronger SHA-2 — it is a completely different design selected by NIST as a structural backup in case future cryptanalysis weakens the SHA-2 family. The two are independent in the sense that breaking SHA-2 would not imply anything about SHA-3, and vice versa. NIST recommends SHA-3 for new designs where structural diversity matters, but SHA-256 remains the workhorse in practice because the entire deployed ecosystem (TLS certificates, code signing, Git, package managers, blockchains) is built on it.
Comparison: MD5 vs SHA-1 vs SHA-256 vs SHA-3 vs BLAKE3
The five major hash families in current use occupy distinct points on the speed-versus-security curve. The table below summarizes their digest sizes, current security status, typical throughput on a modern CPU, and the contexts where each is appropriate.
| Algorithm | Digest Bits | Year Standardized | Security Status | Typical Speed (single core) | Common Uses |
|---|---|---|---|---|---|
| MD5 | 128 | 1992 (RFC 1321) | Broken (collisions trivial) | ~600 MB/s | Cache fingerprints, dedup only — never security |
| SHA-1 | 160 | 1995 (FIPS 180-1) | Broken (SHAttered, 2017) | ~500 MB/s | Legacy Git, deprecated TLS — migrating out |
| SHA-256 | 256 | 2001 (FIPS 180-2) | Strong; no known weakness | ~400 MB/s (1.5 GB/s w/ SHA-NI) | TLS, code signing, Bitcoin, modern Git |
| SHA-3 (Keccak) | 224 / 256 / 384 / 512 | 2015 (FIPS 202) | Strong; structural backup to SHA-2 | ~250 MB/s | Long-term signatures, Ethereum (Keccak-256) |
| BLAKE3 | 256 (variable via XOF) | 2020 (no formal NIST status) | Strong; based on BLAKE2/ChaCha | ~3+ GB/s single-core; 10+ GB/s w/ AVX-512 | Large-file hashing, content addressing, deduplication |
BLAKE3 wins on speed for large inputs. Its single-core throughput is several times higher than hardware-accelerated SHA-256, and its tree-based internal structure parallelizes trivially across cores — a multi-gigabyte file hashed with BLAKE3 on a 16-core machine completes in a fraction of the time SHA-256 takes on the same hardware. The tradeoff is ecosystem adoption: SHA-256 is everywhere, BLAKE3 is in the rust-crypto, restic, and a growing list of newer systems but is not yet standardized by NIST and is not exposed by the browser's Web Crypto API. For pure-browser use today, SHA-256 remains the practical default; for performance-critical native code, BLAKE3 is the modern choice.
Want to verify a hash result against another implementation? The Base64 Encoder handles the encoding conversions between hex, Base64, and Base64url that show up when comparing digests across systems with different output conventions.