Skip to main content

Hash Generator

Generate SHA-1, SHA-256, SHA-384 and SHA-512 hashes from text.

Reviewed by · Last reviewed

Computing a File Checksum or Content Digest

  1. Paste your text into the input textarea. Any Unicode is fine; the tool encodes to UTF-8 bytes before hashing.
  2. Click "Generate Hashes". All four algorithms (SHA-1, SHA-256, SHA-384, SHA-512) compute in parallel via Promise.all on crypto.subtle.digest().
  3. Toggle "Uppercase" if you need to match a checksum that was published in uppercase hex (common on Microsoft download pages and older Linux mirror lists).
  4. Compare the hash character-by-character against the value you expected. A single differing hex digit means the input differs somewhere - there is no "close to correct" in hash space.
  5. Click the Copy icon next to any digest to drop it into your clipboard. The four digests stay on-screen until you hit Generate again with new input.

What a Non-Crypto Hash Actually Does for You

This tool targets the bread-and-butter use case that is not password storage: checking whether two pieces of data are bit-for-bit identical. It hands UTF-8 bytes to crypto.subtle.digest(alg, buffer), the Web Crypto API\'s implementation of SHA-1 (FIPS 180-4 section 6.1), SHA-256 (6.2), SHA-384 and SHA-512 (6.4-6.5). Implementations live in your browser\'s native crypto library (BoringSSL, NSS, CoreCrypto), running at near-hardware speed via SHA-NI on modern Intel and ARM CPUs. Output is fixed-size: 160 bits for SHA-1, 256 for SHA-256, 384 for SHA-384, 512 for SHA-512. Identical inputs always produce identical digests; flipping a single bit changes roughly half the output bits (the avalanche property).

Legitimate Uses Where MD5 and SHA-1 Are Still Fine

  • Verifying an ISO download against the checksum on a mirror\'s SHA256SUMS file before burning to USB.
  • Detecting unintentional corruption when copying a large file between disks - any hash catches bit-rot, magnetic decay, or a flaky USB cable.
  • Git object naming: Git hashes every commit, tree, and blob with SHA-1 (migrating to SHA-256) and uses the digest as the object ID. Not a security function - a content address.
  • Deduplication: Dropbox, Git LFS, and rsync all hash content chunks to avoid re-uploading identical data. MD5 is fine here because the threat model is accidental collision, not adversarial forgery.
  • Generating stable IDs for cache keys, ETags, or HTTP Content-Digest headers where you want a deterministic fingerprint of a response body.
  • Debugging a pipeline by logging the hash of an intermediate payload so you can match it to the same hash in a downstream log without reprinting the full body.

Where This Tool Is the Wrong Answer

Do not use any of these hashes to store passwords. SHA-1, SHA-256, SHA-384, and SHA-512 are all fast by design - a single GPU can compute billions of SHA-256 hashes per second. The LinkedIn 2012 breach exposed 6.5 million unsalted SHA-1 password hashes, and within days cracking rigs had recovered roughly 90 percent of them using the RockYou wordlist. Password hashing needs a slow function (bcrypt, scrypt, Argon2id, or PBKDF2 with 600k+ iterations) that costs milliseconds of CPU time per guess - see the companion PBKDF2 tool on this site. Also do not rely on SHA-1 for collision resistance in any new design: the SHAttered attack (Google, 2017) produced two PDFs with the same SHA-1; Chosen-Prefix Collisions (2020) brought the cost under $50k. GitHub, OpenSSL, and most major projects have moved to SHA-256. Finally, bare SHA-256 is not a message authentication code - if you need to prove the sender knew a shared secret, use HMAC-SHA-256 from the dedicated HMAC tool.

The SHA Family in One Paragraph

SHA-1 was published in 1995 (FIPS 180-1), produces a 160-bit digest, and is considered broken for collision resistance since SHAttered. SHA-256 and SHA-512 were standardized in 2001 (FIPS 180-2, now 180-4) and are based on the Merkle-Damgard construction with a Davies-Meyer compression function. SHA-384 is SHA-512 truncated to 384 bits with a different initialization vector, used by NSA Suite B at the TOP SECRET level. SHA-2 remains cryptographically sound in 2026 with no known pre-image or collision attacks better than birthday-bound brute force. The SHA-3 family (FIPS 202, 2015) is based on the completely different Keccak sponge construction and exists as insurance in case a breakthrough damages SHA-2; it is not in this tool because the Web Crypto API does not expose it. For general integrity checking, SHA-256 is the sweet spot: small output, fast on 32-bit CPUs, hardware-accelerated on modern chips.

CLI and Library Alternatives

On Unix, shasum -a 256 file.iso, sha256sum file.iso, or openssl dgst -sha256 file.iso do the same job and handle files of any size. On Windows, certutil -hashfile file.iso SHA256 or PowerShell\'s Get-FileHash are built in. For gigabyte-scale files, CLI wins decisively because it streams from disk. This tool beats a typical "online hash generator" that uploads your text - here computation happens entirely client-side via crypto.subtle.digest. For hashing inside code, use the language stdlib (hashlib, node:crypto, java.security.MessageDigest) rather than a REST API.

Frequently Asked Questions

Is my input sent to a server at any point?

No. The tool invokes crypto.subtle.digest() from the Web Crypto API, which is implemented natively in your browser engine and performs all computation locally. You can open DevTools Network tab, paste a gigabyte of text, click Generate, and see zero outgoing requests. The page makes no fetch or XHR calls related to hashing. If you are handling regulated data (HIPAA, PCI, GDPR special categories), this matters - the data never leaves your device.

Why does changing one character produce a completely different hash?

This is the avalanche property that defines cryptographic hash functions. Each round of SHA-256 mixes the input state through bit rotations, additions, and the choice/majority nonlinear functions (FIPS 180-4 section 4.1.2). After 64 rounds, any single input bit affects roughly half the output bits with near-equal probability. The practical consequence: two inputs that differ by one space, one newline, or one CR vs LF produce hashes that share no useful bits. This is why Windows vs Unix line endings matter for checksum verification.

Are SHA-1 hashes still safe to use anywhere?

For adversarial use cases, no. The SHAttered attack in 2017 produced two PDFs with identical SHA-1, and Chosen-Prefix Collisions in 2020 brought the cost to around 45,000 dollars. Git still uses SHA-1 as content address but has migration tooling; HTTPS certificates using SHA-1 were deprecated in 2016. For non-adversarial use - comparing file copies, computing a cache key, Git object IDs - SHA-1 remains fit for purpose because the threat is accidental collision, which has probability 2^-80 per pair. Default to SHA-256 for new work; SHA-1 is acceptable only when you can prove the attacker cannot choose both inputs.

Why is MD5 not offered?

The Web Crypto API's digest() method supports only SHA-1, SHA-256, SHA-384, and SHA-512. MD5 was deliberately excluded by the W3C Web Crypto Working Group because it is cryptographically broken (collisions found by Wang in 2004, chosen-prefix attacks shown against CAs by Marc Stevens in 2012). You can still find MD5 in legacy checksum files (SourceForge, older FreeBSD mirrors); for those, use a CLI tool like md5sum. For new work, SHA-256 is the correct choice.

What is the difference between SHA-256 and SHA-512 in practice?

SHA-256 uses 32-bit internal state (8 words of 32 bits) and 64 rounds; SHA-512 uses 64-bit state and 80 rounds. On 64-bit CPUs, SHA-512 is often faster per byte because it processes 1024-bit blocks versus SHA-256's 512-bit blocks. On 32-bit ARM or legacy embedded systems, SHA-256 is faster. Security-wise, both resist all known cryptanalytic attacks. Use SHA-256 for smaller output (32 bytes fits in a Bitcoin address, an IPFS CID, a short URL slug); use SHA-512 when you need extra margin or are building on top (HMAC-SHA-512, SHA-512/256 truncation).

Does this tool handle Unicode correctly?

Yes. Before hashing, the input is encoded to bytes via TextEncoder().encode(text), which emits UTF-8. Emoji, CJK characters, Arabic, right-to-left marks, and combining diacritics round-trip correctly. Note that Unicode normalization matters: "é" (U+00E9) and "é" (e + combining acute U+0301) look identical but have different UTF-8 encodings and therefore different hashes. Normalize to NFC before hashing user-typed text.

Can I use these hashes as unique IDs in a database?

Yes, with collision math in mind. SHA-256 has a 2^128 collision resistance ceiling, so you can generate 10^18 random keys before the probability of a collision crosses one in a billion. For application IDs this is overkill; even truncating to 64 bits gives 2^32 safe keys. Git uses the first 7 hex chars (28 bits) for short commit hashes, which collides in large repos like the Linux kernel. Rule of thumb: 128 bits of hash = 64 bits of collision safety.

How does this compare to running openssl dgst on the command line?

Cryptographically identical - both compute the same FIPS 180-4 SHA-256. Practically, openssl streams files from disk without reading them into memory and integrates with shell scripts. This tool wins for one-off checks of short text, for showing all four digests simultaneously, and for users who do not have a terminal handy.

More Developer Tools