About

SHA-256 produces a 256-bit (32-byte) digest rendered as 64 hexadecimal characters. It belongs to the SHA-2 family designed by the NSA and standardized in FIPS PUB 180-4. This generator does not hash an input string. It produces cryptographically secure random byte sequences of length 32 using the browser's crypto.getRandomValues() CSPRNG, then encodes them as hex - yielding output structurally identical to genuine SHA-256 digests. The collision probability for any two 256-bit values is approximately 1 in 2¹²⁸ (Birthday Paradox bound), making duplicates effectively impossible at any practical scale.

Common use cases include populating database fixtures, generating placeholder API tokens, stress-testing systems that parse hex strings, and creating unique identifiers where format compliance matters but derivation from a source message does not. Note: these values are indistinguishable from real SHA-256 output in format only. They are not derived from any plaintext via the compression function, so they carry no preimage relationship. If you need actual message digests, use a hashing tool instead.

Formulas

A SHA-256 digest is a sequence of 256 random bits. This generator creates that sequence directly using a CSPRNG rather than the SHA-256 compression function:

H = hex(crypto.getRandomValues(Uint8Array[32]))

Each byte b in the 32-byte array is converted to a two-character hexadecimal string:

h_i = b_i.toString(16).padStart(2, "0")

The full hash is the concatenation of all 32 hex pairs, yielding a 64-character string. The probability of collision between any two generated hashes follows the Birthday Bound:

P(collision) ≈ 1 − e^{−n²2²⁵⁷}

Where n = number of hashes generated. Even at n = 10¹⁸, this probability remains negligibly small (< 10⁻³⁸). The entropy source is the operating system's CSPRNG (e.g., /dev/urandom on Linux, BCryptGenRandom on Windows), exposed through the Web Crypto API.

Reference Data

Hash Function	Digest Size (bits)	Hex Length	Block Size (bits)	Rounds	Collision Resistance	Status
MD5	128	32	512	64	2⁶⁴	Broken
SHA-1	160	40	512	80	2⁸⁰	Broken
SHA-224	224	56	512	64	2¹¹²	Secure
SHA-256	256	64	512	64	2¹²⁸	Secure
SHA-384	384	96	1024	80	2¹⁹²	Secure
SHA-512	512	128	1024	80	2²⁵⁶	Secure
SHA-512/256	256	64	1024	80	2¹²⁸	Secure
SHA3-256	256	64	1600	24	2¹²⁸	Secure
SHA3-512	512	128	1600	24	2²⁵⁶	Secure
BLAKE2b	512	128	1024	12	2²⁵⁶	Secure
BLAKE3	256	64	512	7	2¹²⁸	Secure
RIPEMD-160	160	40	512	80	2⁸⁰	Legacy
Whirlpool	512	128	512	10	2²⁵⁶	Secure
Tiger	192	48	512	24	2⁹⁶	Legacy

Frequently Asked Questions

No. These are 256-bit cryptographically random values formatted as 64 hexadecimal characters - structurally identical to SHA-256 output but not derived from any plaintext via the SHA-256 compression function. They have no preimage. Use them as test fixtures, placeholder tokens, or unique identifiers where format compliance matters but derivation does not.

Yes. The generator uses crypto.getRandomValues(), which is backed by the operating system's CSPRNG (e.g., /dev/urandom on Linux, BCryptGenRandom on Windows). This meets the requirements of NIST SP 800-90A for cryptographic random number generation. The output is suitable for security-sensitive applications like token generation.

Theoretically yes, practically no. The Birthday Paradox bound for 256-bit values means you would need approximately 2¹²⁸ (≈ 3.4 × 10³⁸) hashes before a 50% collision probability. Generating 10,000 hashes gives a collision probability of roughly 10⁻⁶⁹. You are more likely to be struck by a meteorite.

Functionally none. Both represent the same 256-bit value. However, conventions differ: Bitcoin uses lowercase, some APIs expect uppercase, and RFC 4648 specifies uppercase for Base16 encoding. Choose the format that matches your target system's expectations to avoid case-sensitive comparison failures.

As primary keys: yes, the collision probability is negligible for any practical database size. As API tokens: they are cryptographically random and sufficiently long (256 bits of entropy), making brute-force infeasible. However, for production authentication tokens, consider using established libraries that also handle timing-safe comparison and rotation policies.

Browser tab memory and DOM rendering are the bottleneck. Generating 10,000 64-character strings is fast (under 50ms), but inserting them into the DOM can cause layout thrashing. The cap keeps the UI responsive. For larger datasets, use the export-to-file feature which writes directly to a Blob without DOM rendering overhead.