SHA Hash Generator - SHA1, SHA256, SHA512

SHA Family — What You're Actually Choosing Between

SHA-1, SHA-256, and SHA-512 are not interchangeable. The right one depends on your threat model, not just "bigger is safer."

Algorithm	Output	Speed (software)	Status	Reach for it when…
SHA-1	160 bits / 40 hex chars	Fast	Deprecated (2017)	Reading legacy git object IDs, old S/MIME. Never for new signatures or certificates.
SHA-256	256 bits / 64 hex chars	Fast on 64-bit	Current standard	TLS certificates, code signing, JWT, file integrity checks, blockchain. Default choice for 99% of work.
SHA-384	384 bits / 96 hex chars	Same as SHA-512*	Current	NSA Suite B compliance, some government procurement requirements. Rarely needed outside that.
SHA-512	512 bits / 128 hex chars	Faster than SHA-256 on 64-bit CPUs	Current	Situations where you want more collision resistance and are running on 64-bit hardware. Also useful when SHA-256 output is used as a key and you need more material.
SHA-512/256	256 bits / 64 hex chars	Faster than SHA-256 on 64-bit CPUs	Current	When you want SHA-256-sized output but SHA-512 throughput on 64-bit. Used by AWS S3 Signature V4.

* SHA-384 and SHA-512 share the same internal round function; SHA-384 just truncates earlier.

Things Developers Get Wrong About SHA

SHA is everywhere, which means its misuse is also everywhere. These are the errors that actually show up in code review.

SHA is not a password hasher

SHA-256 hashes a password in microseconds. That's the problem. A GPU cracking rig runs billions of SHA-256 ops per second. Use bcrypt, scrypt, or Argon2 for passwords — they're designed to be slow. This is probably the most common security mistake in web applications.

SHA-1 collision happened in 2017

The SHAttered attack produced two different PDF files with the same SHA-1 hash. Chrome stopped trusting SHA-1 TLS certificates that year. If you're still accepting SHA-1 hashes as proof of identity for anything security-relevant, stop. For checksums on files you fully control, the risk is low but there's no reason not to upgrade.

Hex vs Base64 output both represent the same hash

A SHA-256 hash is 32 bytes. Hex encoding gives you 64 characters; Base64 gives you 44 characters (with padding). Both represent exactly the same 256-bit value. The format only matters when comparing hashes — you'll get a mismatch if one system uses hex and another uses Base64 for the same algorithm.

Salting only helps with passwords, not hashing in general

People sometimes ask "should I salt my SHA-256 hash?" For file integrity, no — the point is that anyone with the same file gets the same hash. For deriving keys from passwords, salting is critical, but at that point you should be using a KDF like HKDF or PBKDF2, not bare SHA. SHA + a salt is not the same as a proper KDF.

HMAC-SHA256 ≠ SHA256(key + message)

Concatenating a key and message before hashing is vulnerable to length extension attacks. The HMAC construction (RFC 2104) addresses this by XOR-ing two derived keys and running two nested hash passes. Always use HMAC if you need a keyed hash.

Comparing hash strings with == leaks timing info

String comparison exits on the first differing character. An attacker can measure response time differences to guess the hash byte by byte. Use constant-time comparison: crypto.timingSafeEqual() in Node, hmac.compare_digest() in Python, or hash_equals() in PHP.

Where SHA-256 Actually Lives in Production Systems

Concrete examples from real infrastructure — not hypothetical ones.

System	How SHA-256 is used	What breaks if you swap it out
TLS 1.3 certificates	Signature algorithm in X.509 certs. Server proves key ownership by signing the handshake.	Browsers reject the connection. SHA-1 certs are blocked since 2017.
Git	Object IDs for blobs, trees, commits. Git is migrating from SHA-1 to SHA-256 (object-format sha256).	SHA-1 repo: object ID collisions are now a real concern for adversarial content hosting.
Bitcoin / Ethereum	Bitcoin uses double-SHA-256 for block hashing and transaction IDs. Ethereum uses Keccak-256 (not standard SHA-3).	Changing it would require a hard fork — effectively creating a new chain.
JWT (RS256, HS256)	The "256" refers to the hash used in the signature scheme. HS256 = HMAC-SHA256. RS256 = RSA + SHA-256.	Tokens signed with one scheme don't verify with another. The alg header tells the verifier which to use.
Docker image IDs	Image manifests are content-addressed with SHA-256. `sha256:abc123...` uniquely identifies a layer.	Two images with the same ID but different content would be indistinguishable — catastrophic for supply chain security.
S3 / cloud storage ETags	Often MD5 of the object content (single-part) or a derived value (multipart). Verify before assuming it's SHA.	Using SHA where MD5 is expected means your integrity check will always fail.

Related Tools

Other free security and hashing tools on IndexCraft.

Questions That Come Up Constantly

Practical answers without the academic padding.

No. SHA-256 is a one-way function — it is computationally infeasible to derive the original input from the hash output alone. What IS possible: if the input comes from a small, known set (like common passwords), an attacker can pre-compute a lookup table (rainbow table) and reverse the hash that way. This is why you never use bare SHA for passwords, and why salting (adding a random value before hashing) defeats pre-computed tables even when SHA is involved in a KDF chain.

Astronomically small under normal circumstances. SHA-256 has 2²⁵⁶ possible outputs — that's roughly 10⁷⁷ values, more than the estimated number of atoms in the observable universe. A birthday-bound collision would require roughly 2¹²⁸ hash computations, which is completely beyond any hardware that exists or is theoretically feasible. No known collision has ever been produced for SHA-256. This is why it's used for content-addressed storage (Docker, Git with SHA-256 mode, IPFS).

For almost all practical purposes, SHA-256 is fine and has broader library and hardware support. SHA-3 (Keccak) uses a completely different internal construction (sponge vs Merkle-Damgård) which makes it immune to length-extension attacks without HMAC wrapping. If you're building something where length-extension resistance matters without HMAC overhead, SHA-3 is attractive. If you're just doing file integrity, JWT, or TLS, SHA-256 has decades of audit history and is the default in every protocol you're likely to implement.

Yes, always — that's the determinism property. The same byte sequence always produces the same hash. However: line endings matter. A text file with CRLF line endings has a different hash than the same file with LF endings. Metadata (file creation time, permissions) is not part of the hash — only the content. If you're comparing hashes across operating systems, watch out for editors that silently convert line endings.

Legacy compatibility. Some download tools and package managers were written when SHA-1 was the standard. Some even older ones only understand MD5. Providing multiple hashes lets every client verify integrity with whatever algorithm it supports. For a new project in 2024, SHA-256 alone is the right call — there's no reason to also ship a SHA-1 or MD5 checksum unless you explicitly need to support antiquated tooling.

#️⃣ SHA Hash Generator

SHA Hash Algorithms — Reference

SHA-256

SHA-512

SHA-384

SHA-1 & HMAC