Skip to content

Hash Generator, SHA-256 SHA-512

Compute SHA-1, SHA-256, SHA-384, and SHA-512 hashes of any text using the browser Web Crypto API.

In your browser—your files never leave your device.

Learn more
⌘Enter re-hash
Input: 0 bytesActive: SHA-256 (256-bit)
SHA-1 · 160-bit
hash will appear here…
SHA-256 · 256-bit
hash will appear here…
SHA-384 · 384-bit
hash will appear here…
SHA-512 · 512-bit
hash will appear here…

About this tool

A cryptographic hash takes any input and produces a fixed-length string that changes wildly if the input changes by one bit and is impossible to reverse in any practical sense. SHA-2 (the family that includes SHA-256, SHA-384, and SHA-512) is the modern default for everything from file checksums to commit hashes to API request signatures. SHA-1 still exists in the wild — Git uses it for object IDs, plenty of legacy systems use it for checksums — but it has been cryptographically broken for collision resistance since 2017 (the SHAttered attack from CWI Amsterdam and Google), so it is fine for non-security uses and wrong for anything where forging matters. This tool runs SubtleCrypto.digest in your browser and outputs hex strings identical to what Python hashlib, Node crypto.createHash, or any standards-compliant library produces.

How to hash generator, sha-256 sha-512

  1. Type or paste your input

    Any text, any length. Empty input shows blank hashes; one character produces 40/64/96/128 hex characters respectively. The input is treated as a UTF-8 byte string, which matches what hashlib and crypto.createHash do by default in their respective languages.

  2. Read all four hashes

    The page shows SHA-1, SHA-256, SHA-384, and SHA-512 side by side, recomputing as you edit the input. Pick whichever your use case demands. For verification against a published hash, the algorithm is usually specified next to the hash value (e.g. "sha256: abc123...").

  3. Copy the one you need

    Each hash has its own copy button. Click and the hex string lands on your clipboard. The copy includes only the hash, not the algorithm label, so you can paste it directly into a comparison check.

  4. Compare

    Paste the computed hash into your verification target — a checksum file, a signed-URL parameter, an audit log — and confirm it matches. If you are doing this for download verification, the standard is to compare visually or with a single-line diff (diff <(echo "$expected") <(echo "$actual") in bash).

Why use this tool

Verifying a download checksum is the classic case. You download a Linux ISO or a release binary, the project publishes a SHA-256 alongside it, you compute the hash locally and compare. If they match, the file was not tampered with in transit and was not served from a compromised mirror. This tool gives you the SHA-256 of any text instantly — for files, a CLI is usually easier (shasum -a 256 on macOS, sha256sum on Linux, certutil -hashfile on Windows). The second case is signing API requests: Stripe webhook signatures, AWS SigV4 request signing, GitHub webhook HMACs all involve hashing a canonical request string. Pasting the canonical string here and comparing the hash against what the signature implies is how you debug "signatures do not match" errors. The third case is generating consistent IDs from content (content-addressable storage like IPFS, Git blob IDs, etc.) — same input always gives the same hash, so you can detect duplicates without storing the original. The fourth: quickly checking whether two long strings are identical — compare hashes (64 hex chars for SHA-256) instead of diffing the full content. The fifth is computing the SHA hash of a password input client-side before sending it for further processing (though for password storage proper, see below).

Features

Four algorithms in parallel

SHA-1, SHA-256, SHA-384, SHA-512 all compute on the same input and display together. No need to pick first. Useful when you are not sure which one the spec needs, or when you want to compare lengths (SHA-1 is 40 hex chars, SHA-256 is 64, SHA-384 is 96, SHA-512 is 128). The parallel computation costs almost nothing extra because SubtleCrypto is highly optimized; you get all four for the price of one.

Web Crypto API under the hood

SubtleCrypto.digest is a browser-native primitive — same code path Node's crypto module uses on the server, same underlying implementation as OpenSSL on most platforms. Output is identical hex-for-hex with hashlib.sha256(input.encode()).hexdigest() in Python, crypto.createHash("sha256").update(input).digest("hex") in Node, and equivalent calls in Go, Rust, or Java. No "JavaScript-flavored" hash — these are the real, standards-compliant outputs that interoperate with every backend.

Live computation with debounce

Hashes update as you type with a tiny debounce so the page does not stutter on long inputs. Drop in a few hundred KB of text and the hash appears in milliseconds. Empty input shows blank hashes; one character of input produces a full 40-char SHA-1 and 64/96/128-char SHA-2 hashes that all change completely when you add or remove a single byte. That avalanche property is the whole point of cryptographic hashing.

Local-only execution

crypto.subtle.digest runs in the browser. Your input is not transmitted. This matters because the most common reason to hash a string in a tool is to compare it against a known hash without revealing the original — typing a password or a secret into a server-side hash tool would be exactly the wrong move because the server then sees the secret directly. Open DevTools, watch the Network tab, hash anything, and confirm no outbound requests.

Matches NIST test vectors exactly

NIST publishes official test vectors for SHA-2 in FIPS 180-4 — known input strings paired with their expected hash output. Hashing the empty string with SHA-256 must produce e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. Hashing the string "abc" must produce ba7816bf8f01cfea414140de5dae2223b00361a3396177a9cb410ff61f20015a. This tool produces those exact values because SubtleCrypto.digest is required by the W3C Web Crypto spec to implement FIPS 180-4 compliantly. If you ever get a different output for a known input, the bug is in the input encoding (UTF-8 vs UTF-16 vs Latin-1) — never in the algorithm.

Privacy & security

SubtleCrypto.digest runs in the browser using the same FIPS 180-4 implementation OpenSSL ships on most platforms. Your input string is converted to UTF-8 bytes by TextEncoder, the digest is computed in your tab, and the hex output is rendered into the DOM. Hashing is one of those operations where running it remotely defeats the point: the most common reason to hash a string is to derive a verifier without exposing the original secret, and pasting that secret into a server-side tool would directly contradict the goal.

Frequently asked questions

Why is MD5 missing?
SubtleCrypto does not expose MD5 — the W3C decided not to ship a known-broken algorithm in a modern API. MD5 has been broken for collision resistance since 2004 and the W3C draws the line. You can still find MD5 in checksums for non-security use (some torrent files, some legacy installers, some CMS export formats), and if you really need it, a small JavaScript library (spark-md5 is the standard pick) or a one-liner via openssl/md5sum on the command line is the move. For new use cases, pick SHA-256 instead — it is barely slower and not broken.
SHA-1 is broken, so why include it?
Broken for collision resistance means an attacker who controls both inputs can find a pair that hashes to the same value. That matters for digital signatures and certificate validation, where it would let an attacker forge documents — TLS certificates with SHA-1 signatures were retired around 2016 for this reason. It does not matter for use cases like Git object IDs or non-security checksums, where you only care about accidental corruption and you trust the inputs. Plenty of systems still use SHA-1 for these — Git is the obvious one, despite a long-planned migration to SHA-256. So it stays in the tool for those workflows. Just do not use SHA-1 for new security-relevant hashing.
Which hash should I pick for password storage?
None of these. SHA-256 is too fast for password hashing — an attacker with a GPU farm can try billions of guesses per second against a leaked database of SHA-256 hashes, even when those hashes are salted. Use a slow, salted, memory-hard password hash like bcrypt, scrypt, or Argon2id, which are designed to be expensive to compute (deliberately taking 100ms+ per hash) and resist GPU and ASIC attacks. SHA-256 is the right primitive for HMAC, content addressing, signatures, and request fingerprinting — not for password storage.
Does the output match hashlib.sha256 or crypto.createHash exactly?
Yes. SubtleCrypto.digest produces standard SHA-256 over the input bytes; hashlib.sha256(text.encode()) and crypto.createHash("sha256").update(text).digest("hex") produce the same bytes from the same input. The only gotcha is text encoding — both this tool and a typical .encode() default to UTF-8. If you hash the same string with one tool using UTF-8 and another using UTF-16 or Latin-1, you get different hashes; that is the input being different at the byte level, not the algorithm. Always confirm encoding when comparing hashes across systems.
Can I hash a file with this tool?
Not directly — it takes text input. For files, the CLI is faster anyway: shasum -a 256 file.iso on macOS, sha256sum file.iso on Linux, Get-FileHash file.iso on PowerShell, or certutil -hashfile file.iso SHA256 on Windows cmd. Browser-side file hashing is possible with FileReader and SubtleCrypto in a few lines of code; for one-off file hashing the CLI is one line and faster than uploading the file into a browser.
SHA-256 versus SHA-512 — which one should I pick?
Both are 64-bit secure (no practical attacks). SHA-512 is faster on 64-bit hardware because its internal block size matches the CPU word size, but the output is twice as long (128 hex chars vs 64) so it takes more storage and bandwidth. For most use cases SHA-256 is the right default — it is what TLS, Git's post-SHA-1 migration, most cryptocurrency systems, and most APIs use. SHA-512 makes sense when you specifically want the extra margin (long-lived signatures intended to outlast quantum computing concerns, future-proofing), when you are on a 64-bit-only platform where speed matters and the size penalty is acceptable, or when a spec explicitly requires it.
What is a salt and why do I see it mentioned?
A salt is a random value mixed into the input before hashing, so identical inputs produce different hashes. Without salt, two users with the same password produce the same hash, and an attacker can precompute (rainbow tables) the common passwords once and crack many at a time. Salt is essential for password storage and irrelevant for non-secret hashing (file checksums, content addressing, HMAC where the key already serves the role salt would). To demonstrate salt behavior with this tool, prepend or append a random string to the input before hashing and you will see how different the hash becomes.
What is HMAC and how is it different from a plain hash?
HMAC (Hash-based Message Authentication Code) combines a secret key with the input before hashing in a specific way that prevents length-extension attacks and other manipulations. HMAC-SHA256 is what Stripe, GitHub, and AWS use to sign webhook payloads and API requests. This tool computes plain hashes (no key), so it is not suitable for verifying HMAC signatures directly — for that you need a tool that takes both the key and the message. Most language standard libraries have HMAC as a one-line call.
Privacy concerns?
None. The hashing runs in your browser via SubtleCrypto. The input never goes over the network. Open DevTools, switch to Network, paste an API secret you need to hash — there are no outbound requests. This matters specifically for hashing because the whole point of computing a hash is often to derive a verifier without exposing the underlying secret; running the hash on a server would defeat that.
SHA-2 versus SHA-3 — what is the actual difference?
They are two different hash families designed by different teams using different internal math. SHA-2 (which includes SHA-256, SHA-384, SHA-512) was designed by the NSA in 2001 and uses a Merkle-Damgård construction with a compression function called Davies-Meyer. SHA-3 (with variants SHA3-256, SHA3-512, etc.) was selected through a public NIST competition in 2012, won by the Keccak algorithm, and uses a completely different "sponge" construction. Both are unbroken and considered secure for the foreseeable future. SHA-3 was created as an insurance policy in case a structural weakness in SHA-2 was ever found — if SHA-2 fell, SHA-3 would not fall with it. In practice SHA-2 is what almost everything uses today (TLS, Git, Bitcoin, most APIs). SHA-3 sees use in some newer protocols (Ethereum uses Keccak-256, which is technically a pre-standard SHA-3 variant) but it is not yet exposed by Web Crypto, so this tool does not generate SHA-3 hashes.
Why is the SHA-256 collision space ($2^{128}$) considered unimaginably large?
A 256-bit hash gives 2^256 possible values. By the birthday bound, finding any two inputs that hash to the same output takes about 2^128 attempts on average — that is the practical security level. 2^128 is about 3.4 × 10^38, a number with 39 digits. For comparison, the number of atoms in the observable universe is estimated at around 10^80, the number of stars in the observable universe is around 10^24, and the age of the universe in nanoseconds is around 10^26. Even with a million times the world's current computing capacity running flat out for the entire age of the universe, you would not crack 2^128 — you would not come close. This is why "SHA-256 is broken" is not a thing anyone serious says without major qualifications. There are theoretical attacks that reduce the security margin by a few bits, but nothing remotely close to the kind of leap that broke SHA-1 (which dropped from 2^80 to 2^63 in 2017 with SHAttered).
Why does this tool not include MD5 or SHA-1 by default?
SubtleCrypto.digest does not expose MD5 at all (the W3C declined to ship a known-broken algorithm in a new API). SHA-1 is still available because Git, some legacy webhook systems, and several enterprise file-integrity workflows still depend on it. The tool shows SHA-1 alongside the SHA-2 family for those cases, with the understanding that you are not using it for security-relevant work like signing or password hashing. MD5 is genuinely worse — published collision attacks since 2004, complete collision generation in seconds on a laptop since 2008 — and a modern tool punishing developers for picking it is not the goal, but actively offering it as an option would be misleading. For non-security file integrity checks where MD5 is still standard (some torrent files, some old installer bundles), use the openssl md5 CLI command or your platform's file manager. For everything else, SHA-256 is the right default.
I salted my password hashes with SHA-256 — am I good?
No. Salting solves one problem (rainbow tables for common passwords) but does nothing about the other problem (raw GPU speed). Modern GPU farms compute SHA-256 at billions of hashes per second. A leaked database of salted SHA-256 password hashes is still a disaster — an attacker who steals the database can try every word in every dictionary plus common patterns ("password123", "qwerty2024", and so on) against each user's hash in under an hour. The defense is to make the hash itself slow, not just unique. bcrypt, scrypt, and Argon2id are designed to take 100ms+ per hash, parameterized so you can tune the cost. Even a small bcrypt cost factor reduces GPU throughput by a million times compared to raw SHA-256. If you have a system using "salted SHA-256" for passwords today, migrate users to Argon2id on next login — pretend the SHA-256 hash never existed.
What encoding does the tool use for the input?
UTF-8. Every character you type or paste is converted to its UTF-8 byte representation before hashing — ASCII characters get one byte each, most European accented characters get two bytes, CJK characters get three bytes, emoji get four bytes. This matches what hashlib.sha256(s.encode()) produces in Python (since the default encoding for .encode() is UTF-8), what Node's Buffer.from(s).digest() produces in Node.js, and what most other modern libraries do. If a hash you computed elsewhere does not match this tool, the input encoding is the first place to check — Windows-era tools that default to UTF-16 or Latin-1 will produce different bytes from the same visible characters, and therefore different hashes. The fix is to confirm both sides use UTF-8 and re-hash.