About

SHA-2 (Secure Hash Algorithm 2) is a family of cryptographic hash functions published by NIST in 2001 as FIPS 180-4. The family includes SHA-256, SHA-384, and SHA-512, producing digests of 256, 384, and 512 bits respectively. This tool generates genuine SHA-2 hashes by feeding cryptographically secure random bytes (32 bytes from crypto.getRandomValues) into the browser's native crypto.subtle.digest engine. The output is not a random hex string that merely looks like a hash. Each value is a real digest with the avalanche property and pre-image resistance expected of SHA-2.

Incorrect hash generation matters. Using predictable seeds or pseudo-random hex strings in test fixtures, database seeding, or integrity-check scaffolding introduces subtle bugs that surface only in production. A mock hash will not collide-resist like a real one, and length mismatches between SHA-256 (64 hex chars) and SHA-512 (128 hex chars) break schema validations silently. This generator eliminates that risk by computing actual digests against random entropy.

Formulas

Each hash is produced by computing a genuine SHA-2 digest over 32 bytes of cryptographically secure random data.

H = SHA-2(R)

where R = crypto.getRandomValues(32 bytes) and H is the resulting digest encoded as a hexadecimal string.

The hex encoding converts each byte b of the raw digest to its two-character hexadecimal representation:

hex = n−1∑i=0 b_i.toString(16).padStart(2, "0")

where n = digest length in bytes: 32 for SHA-256, 48 for SHA-384, 64 for SHA-512. The output hex string length is 2n characters. Collision probability for two randomly generated hashes follows the birthday bound: approximately 2^n/2 hashes needed before a 50% collision chance. For SHA-256, that is 2¹²⁸ ≈ 3.4 × 10³⁸ hashes.

Reference Data

SHA-2 Variant	Digest Size (bits)	Hex Length (chars)	Block Size (bits)	Rounds	Word Size (bits)	Collision Resistance (bits)	Pre-image Resistance (bits)	NIST Standard
SHA-224	224	56	512	64	32	112	224	FIPS 180-4
SHA-256	256	64	512	64	32	128	256	FIPS 180-4
SHA-384	384	96	1024	80	64	192	384	FIPS 180-4
SHA-512	512	128	1024	80	64	256	512	FIPS 180-4
SHA-512/224	224	56	1024	80	64	112	224	FIPS 180-4
SHA-512/256	256	64	1024	80	64	128	256	FIPS 180-4
SHA-1 (deprecated)	160	40	512	80	32	61 (broken)	160	FIPS 180-4 (legacy)
MD5 (broken)	128	32	512	64	32	18 (broken)	128	RFC 1321 (obsolete)
SHA-3-256	256	64	1088	24	64	128	256	FIPS 202
BLAKE2b-256	256	64	1024	12	64	128	256	RFC 7693
BLAKE3	256	64	512	7	32	128	256	N/A (2020)
Whirlpool	512	128	512	10	8	256	512	ISO/IEC 10118-3

Frequently Asked Questions

Every output is a genuine SHA-2 digest. The tool feeds 32 bytes of entropy from crypto.getRandomValues into the browser's native crypto.subtle.digest function. The result has all cryptographic properties of SHA-2: avalanche effect, deterministic output for identical input, and pre-image resistance. A random hex string of 64 characters would statistically appear indistinguishable, but it would not be the output of the compression function and could not be verified against any input.

SHA-256 produces a 256-bit (64 hex character) digest and is used in Bitcoin, TLS certificates, and most integrity checks. SHA-384 outputs 384 bits (96 hex characters) and is common in government and financial systems requiring higher security margins. SHA-512 produces 512 bits (128 hex characters) and is faster than SHA-256 on 64-bit processors due to its native 64-bit word size. Choose based on your protocol's requirements: most applications default to SHA-256.

Theoretically yes, but the probability is negligible. For SHA-256, you would need approximately 2^128 (about 3.4 × 10^38) hashes before reaching a 50% collision probability via the birthday paradox. Generating 1,000 hashes per second continuously, it would take roughly 10^28 years. No SHA-2 collision has ever been found in practice.

Math.random uses a PRNG (typically xorshift128+) that is not cryptographically secure. Its output can be predicted if the internal state is known. crypto.getRandomValues sources entropy from the operating system's CSPRNG (e.g., /dev/urandom on Linux, BCryptGenRandom on Windows), providing unpredictable, non-reproducible randomness suitable for security-sensitive applications.

No. The random input bytes are generated ephemerally and discarded after hashing. This is by design - the tool produces standalone hashes for testing, seeding, and placeholder purposes. If you need verifiable input-output pairs, hash a known string instead using a dedicated hashing tool.

Yes. No practical collision, pre-image, or second pre-image attacks exist against any SHA-2 variant. NIST continues to recommend SHA-2 for all applications. SHA-3 (Keccak) exists as an alternative, not a replacement. The only deprecated predecessor is SHA-1, which was practically broken in 2017 by the SHAttered attack.