Free String Hash Visualiser

How It Works

1. Enter your text: Type or paste any string, a password, file content, identifier, or any text you want to hash.
2. Choose an algorithm: Select MD5, SHA-1, SHA-256, SHA-384, or SHA-512 depending on your use case.
3. Copy the hash: The hash value appears instantly. Copy it for storage, comparison, or verification.

Why Use String Hash Generator?

Hashing converts any string into a fixed-length fingerprint that is unique to its content. Even a one-character change produces a completely different hash. This is essential for verifying data integrity, storing passwords securely, generating cache keys, deduplicating records, and creating content-based identifiers. Because hashing is one-way, you cannot reverse a hash to get the original text, making it safe for storing sensitive data.

Features

• Multiple algorithms: MD5, SHA-1, SHA-256, SHA-384, and SHA-512 all available in one tool.
• Real-time hashing: Hash updates instantly as you type, no button click required.
• Case-sensitive processing: "Hello" and "hello" produce different hashes by design.
• Copy to clipboard: One-click copy of the hash value.
• 100% browser-based: Strings never leave your device, safe for sensitive content.

Frequently Asked Questions

Which hash algorithm should I use?

For security-sensitive applications (passwords, signatures), use SHA-256 or SHA-512. MD5 and SHA-1 are deprecated for security but still useful for checksums and cache keys where cryptographic strength is not required.

Can I use this to hash passwords for storage?

String hashing gives you a one-way hash, but for password storage you should use a key-derivation function like bcrypt, Argon2, or PBKDF2 that incorporates salting and iteration. Simple SHA hashes are too fast and vulnerable to rainbow table attacks.

Are hashes reversible?

No. Hash functions are one-way, you cannot recover the original string from its hash. If two strings produce the same hash (a collision), that is a flaw in the algorithm. SHA-256 and SHA-512 have no known practical collisions.

A 35-year history of hash functions: from MD5 to BLAKE3

Cryptographic hash functions evolved through a long sequence of break-and-replace cycles. MD5 was published by Ronald Rivest in RFC 1321 (April 1992) as a successor to MD4. Its 128-bit output was considered strong enough for over a decade until Wang and Yu published the first practical collision in 2004. By 2008, researchers had used MD5 collisions to forge a rogue SSL certificate authority. SHA-1 was designed by the NSA and standardised by NIST in FIPS 180-1 (1995). Its 160-bit output stood until February 2017, when Google and CWI Amsterdam announced the SHAttered attack, producing two PDFs with the same SHA-1 hash. Costs: about 6,500 CPU-years equivalent on GPUs. SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512), also from the NSA, was published in FIPS 180-2 (August 2002). It uses the same Merkle-Damgård construction as SHA-1 but with larger states and more rounds; no practical attack exists on the full versions today. SHA-3 (Keccak, by Bertoni et al.) was selected by NIST after a public competition and standardised in FIPS 202 (August 2015). SHA-3 uses a completely different sponge construction, immune to the length-extension attacks that affect SHA-2. Outside the NIST family, BLAKE2 (Aumasson et al., 2012) and BLAKE3 (2020) offer SHA-3-class security with the speed of MD5; BLAKE3 hashes a 1 GB file in about a second on a modern laptop.

Which algorithm to pick: a quick decision table

• MD5 (128 bits). Broken since 2004. Acceptable for non-security uses: cache busting, deduplicating files where you control both sides, checksums against accidental corruption. Never use for passwords, signatures, or any adversarial context.
• SHA-1 (160 bits). Broken since 2017 (SHAttered). Git still uses it for commit hashes, but in March 2017 Git started embedding collision detection (SHA-1DC) to refuse known attack patterns. Avoid SHA-1 for new code.
• SHA-256 (256 bits). The current workhorse. Used by Bitcoin, TLS certificates, Linux package signatures, JWT signing (HMAC-SHA256), and most modern APIs. Fast in hardware (Intel SHA extensions, ARMv8 cryptography extensions). Default choice for general-purpose hashing.
• SHA-512 (512 bits). Same family, larger output. Slightly faster than SHA-256 on 64-bit machines because its internal state is 64-bit. Use when you need extra collision resistance or when 256 bits feels constraining (rare).
• SHA-3 / Keccak (224/256/384/512 bits). The standardised sponge alternative to SHA-2. Resistant to length-extension attacks that affect SHA-2 (relevant when building keyed hashes without HMAC). Slower in software than SHA-256 on most CPUs but immune to a different class of attacks.
• BLAKE2 / BLAKE3. Modern non-NIST alternatives. BLAKE3 is the fastest cryptographic hash widely available, hashing at roughly memcpy speed thanks to parallelism. Used in b3sum, IPFS, and the WireGuard VPN protocol. Not yet in crypto.subtle, but available via libraries.

Where hashing actually gets used

• File integrity verification. Linux distributions publish SHA-256 sums next to ISO downloads so you can verify the file was not corrupted in transit or modified by an attacker. sha256sum -c ubuntu.sha256 in 10 seconds.
• Content-addressed storage. Git uses SHA-1 (transitioning to SHA-256) to identify every commit, tree, and blob. IPFS, Docker images (sha256:...), and Nix store paths all use content addressing. The hash IS the identifier.
• Cache keys. Hashing a URL or a serialised request gives you a fixed-length key that fits any storage system. Stripe, GitHub, every CDN uses this for cache lookups.
• Deduplication. Backup systems (Time Machine, Borg, Restic) hash file blocks and only store unique ones. Two identical 4 KB blocks across different files map to one stored chunk.
• HTTP ETags. Web servers send the hash of a response as the ETag header. Browsers send it back with If-None-Match; the server returns 304 if unchanged. Saves redundant downloads.
• JWT and webhook signatures. JSON Web Tokens sign their payload with HMAC-SHA256 (HS256 in the spec). Stripe, GitHub, Twilio webhooks all sign their payloads so you can verify they were not tampered with in transit.
• Blockchains. Bitcoin uses double-SHA-256 for proof-of-work and block linking. Ethereum uses Keccak-256 (a SHA-3 variant). The whole concept of a blockchain rests on the property that finding two inputs with the same hash is computationally infeasible.

Hashing mistakes that lose money or break things

• Using SHA hashes for password storage. SHA-256 is fast: a modern GPU computes ~10 billion SHA-256 hashes per second. With a leaked database, an attacker can try every word in a dictionary plus all common transformations in minutes. Use Argon2id (winner of the 2015 Password Hashing Competition), bcrypt, or scrypt. They are deliberately slow and memory-hard.
• Forgetting to salt. Even with a slow hash, the same password hashed without salt produces the same output across users, enabling rainbow tables and side-channel detection of duplicate passwords. Always store a per-user random salt alongside the hash.
• Length-extension attacks on SHA-2. hash(secret + message) with SHA-256 is vulnerable: an attacker who knows the hash and the length of secret can append arbitrary data and compute the resulting hash without knowing secret. Use HMAC-SHA256 instead. SHA-3 and BLAKE2/3 are immune.
• String comparison in constant time. Comparing hashes (or any secret value) with == in JavaScript leaks information through timing: a function that exits at the first byte mismatch lets attackers learn the correct hash byte by byte over many requests. Use crypto.timingSafeEqual in Node, hmac.compare_digest in Python.
• Hashing strings without specifying encoding. sha256("hello") in Python 3 errors out (you need bytes); in Node it defaults to UTF-8; in PHP and Java the default may vary. Different encodings produce different hashes. Always encode as UTF-8 explicitly before hashing.
• Truncating hashes for «short IDs». A 64-bit slice of SHA-256 is convenient for short IDs but the birthday paradox means collisions appear at ~2³² items (about 4 billion), not 2⁶⁴. If you truncate, plan for collision handling at the expected scale.
• Treating hash output as a URL-safe string. Raw hash bytes are not printable. Use hex (most common) or base64url. Standard base64 contains + and / which break in URLs and filenames; base64url is the safe variant.

More frequently asked questions

Why are MD5 and SHA-1 «broken» if they still produce hashes?

«Broken» means an attacker can produce collisions faster than brute force. For MD5, finding two inputs with the same hash takes seconds on a laptop today. For SHA-1, it took 6,500 CPU-years in 2017 and has dropped dramatically since. The hashes still work mechanically; what's broken is the security guarantee that they are «collision-resistant». For non-adversarial uses (checksumming a file you trust against accidental corruption) MD5 still works fine. For anything involving an adversary, both are unsafe.

Should I worry about quantum computers breaking SHA-256?

Less than you might think. Grover's algorithm speeds up preimage attacks against a 256-bit hash from 2²⁵⁶ to 2¹²⁸ classical-equivalent work, which is still effectively impossible. Symmetric primitives (hashes, AES) survive quantum computing by doubling key/output sizes. Public-key crypto (RSA, ECDSA) is what falls hard to quantum attacks, hence the NIST post-quantum standards published in August 2024 (ML-KEM, ML-DSA, SLH-DSA). If you are using SHA-256 today, SHA-512 in the post-quantum era will be more than enough.

What's the difference between a hash and HMAC?

A hash (SHA-256) is keyless: anyone with the input can compute the same output. An HMAC (Hash-based Message Authentication Code) wraps the hash with a secret key, so only someone knowing the key can compute or verify the tag. Defined in RFC 2104 (1997), HMAC is the standard way to «sign» a message symmetrically (sender and receiver share a secret). Use HMAC-SHA256 for webhook signatures, JWT HS256, API request signing. Plain SHA-256 on secret + message is unsafe due to length-extension.

Why do different libraries give different hashes for the same string?

Three common causes. First, character encoding: UTF-8 vs UTF-16 vs Latin-1 give different bytes for non-ASCII strings, hence different hashes. Always encode explicitly. Second, line endings: "hello\n" and "hello\r\n" hash differently; Windows-vs-Unix file checksums often differ for this reason. Third, output format: lowercase hex vs uppercase hex vs base64 looks like a different value but represents the same bytes. Normalise input and output formats before comparing.

Is my input sent to a server when I hash here?

No. All four hashes are computed in your browser using the built-in Web Crypto API (crypto.subtle.digest). Open the Network tab in DevTools and type into the input, you will see zero outbound requests. Safe for credentials, tokens, or any private value you want to hash without it leaving your device.