Lowercase hexadecimal string — 2 chars per byte.
Uses
crypto.getRandomValues — CSPRNG
No bytes generated yet
Configure options and click Generate// generate cryptographically secure random bytes
Generate cryptographically secure random byte arrays in hex, base64, or uint8 format. Free browser-based tool — no upload, no server storage.
Lowercase hexadecimal string — 2 chars per byte.
crypto.getRandomValues — CSPRNG
No bytes generated yet
Configure options and click GenerateChoose a preset (16–256) or type any value from 1 to 65 536.
Select HEX, BASE64, or UINT8[] depending on your use case.
Click Generate, then copy the output or download it as a .txt file.
This tool generates cryptographically secure random bytes directly in your browser using crypto.getRandomValues() — the same CSPRNG used by TLS and modern password managers. No data ever leaves your device.
Output formats: hex for most developer use cases, base64 for compact transport (e.g. Authorization headers), and uint8 for direct use in WebCrypto or Node.js buffers.
Yes. The tool uses crypto.getRandomValues(), which is the browser's cryptographically secure pseudorandom number generator (CSPRNG). This is the same source of entropy used by TLS handshakes and the Web Crypto API. It is suitable for key material, salts, tokens, and nonces.
No. All byte generation happens entirely client-side in your browser using JavaScript. No random data, settings, or output is ever transmitted to any server. Your generated bytes stay on your device.
OWASP recommends a minimum of 16 bytes (128 bits) for session tokens. For most security-sensitive purposes — API keys, CSRF tokens, encryption keys — 32 bytes (256 bits) is the common standard and considered highly secure.
Hex encodes each byte as two lowercase (or uppercase) hexadecimal characters, giving 2× the original byte count in characters. Base64 is more compact (~1.33×) and is commonly used in HTTP headers and JSON payloads. Uint8 outputs a comma-separated list of decimal integers (0–255) for direct use in JavaScript Uint8Array or Node.js Buffer.
Yes. AES-128 requires 16 bytes, AES-192 requires 24 bytes, and AES-256 requires 32 bytes. Set the byte length accordingly and use the hex or base64 output. For the Web Crypto API, the uint8 format is most convenient as it maps directly to a Uint8Array.
The tool supports up to 65 536 bytes (64 KB) per generation. This covers virtually all practical use cases including large IV buffers, test vectors, and seeding data. Generating very large byte arrays (e.g. 64 KB) may produce very long output strings — use the download option in those cases.
A secure random bytes generator produces byte arrays using a cryptographically secure pseudorandom number generator (CSPRNG) — an algorithm whose output is statistically indistinguishable from true randomness and computationally infeasible to predict or reproduce. Unlike Math.random() in JavaScript (which uses a non-cryptographic PRNG), our tool relies on crypto.getRandomValues(), the browser's built-in CSPRNG backed by the operating system's entropy pool.
💡 Looking for premium web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and developer resources — worth checking out.
The adjective "cryptographically secure" carries precise technical meaning. A CSPRNG must satisfy two properties: it must pass all polynomial-time statistical tests for randomness, and it must be computationally indistinguishable from a true random oracle even if an adversary knows the algorithm. This contrasts with simpler PRNGs used for simulations or games, which trade security for speed and predictability — entirely unsuitable for key material.
When your session token, encryption key, or CSRF nonce is predictable, an attacker can brute-force or enumerate it directly. A 32-byte CSPRNG output has 2256 possible values — more than the estimated number of atoms in the observable universe — making exhaustive search impossible with any foreseeable computing power.
The generator supports three output representations of the same underlying random bytes:
Hexadecimal (Hex) — The most common format for developers. Each byte is encoded as exactly two hexadecimal digits (0–9, a–f), producing a string of length 2 × byteCount. Hex strings are safe to embed in URLs, JSON, HTTP headers, and configuration files. Most programming languages accept hex directly: bytes.fromhex() in Python, Buffer.from(hex, 'hex') in Node.js, hex::decode() in Rust.
Base64 — A binary-to-text encoding that represents every 3 bytes as 4 ASCII characters, resulting in a ~33% size overhead. Base64 is the de facto standard for embedding binary data in HTTP Authorization headers, JWT tokens, TLS certificates, and JSON API payloads. It is more compact than hex for large byte arrays and supported natively by all modern platforms.
Uint8 Array — A comma-separated list of decimal integers (each 0–255) representing each byte's value. This format maps directly to new Uint8Array([...]) in JavaScript, bytes([...]) in Python, and []byte{...} in Go. It is the most convenient format when working with the Web Crypto API or Node.js Buffer operations, as it can be pasted into source code without any additional parsing.
Session tokens and API keys — Authentication systems should generate session IDs and API keys from a CSPRNG with sufficient entropy. OWASP recommends at least 128 bits (16 bytes). Using 32 bytes (256 bits) provides a comfortable security margin and is the industry standard for modern APIs. Generate, encode as hex or base64, and store the hash (e.g. SHA-256) in your database — never the token itself.
Password hashing salts — When using Argon2, bcrypt, or PBKDF2, each password hash requires a unique cryptographic salt to prevent rainbow table attacks and ensure that two identical passwords produce different hashes. A 16-byte random salt is standard. Our tool generates these salts in hex format, ready to store alongside the hash.
Encryption IVs and nonces — AES-GCM requires a 12-byte nonce (IV) that must never be reused with the same key. AES-CBC uses a 16-byte IV. ChaCha20-Poly1305 uses a 12-byte nonce. Generating a fresh random value per encryption operation is the correct practice — our tool produces exactly these sizes with a single click.
CSRF tokens — Cross-site request forgery protection relies on per-session tokens that are unpredictable to an attacker. A 32-byte random value encoded as hex is more than sufficient. Embed it in forms as a hidden field, verify server-side on each state-changing request.
Cryptographic key material — AES-128 needs 16 bytes, AES-256 needs 32 bytes, HMAC-SHA256 keys are typically 32–64 bytes. When the Web Crypto API's generateKey is unavailable or you need to derive keys from a master secret, generating raw bytes and importing them via importKey with format: 'raw' is the standard approach.
All major browsers expose window.crypto.getRandomValues(typedArray), defined in the W3C Web Cryptography API specification. Internally, browsers seed this function from the operating system's entropy sources — on Linux this is /dev/urandom (backed by the kernel entropy pool), on Windows it is BCryptGenRandom (CNG), and on macOS/iOS it is SecRandomCopyBytes. These OS-level CSPRNGs continuously accumulate entropy from hardware events: interrupt timings, disk I/O, mouse movements, and — on supported hardware — dedicated entropy instructions like Intel's RDSEED/RDRAND.
The Web Crypto API ensures this entropy is accessible in browser JavaScript with no additional dependencies. Our tool wraps a single crypto.getRandomValues(new Uint8Array(n)) call, then transforms the buffer into whichever output format you select. Nothing is cached, persisted, or sent anywhere.
Use this table as a quick reference for common cryptographic byte lengths:
| Use Case | Bytes | Bits | Hex Length | Base64 Length |
|---|---|---|---|---|
| AES-128 key | 16 | 128 | 32 | 24 |
| Salt (min OWASP) | 16 | 128 | 32 | 24 |
| AES-GCM nonce | 12 | 96 | 24 | 16 |
| AES-CBC IV | 16 | 128 | 32 | 24 |
| Session token (min) | 16 | 128 | 32 | 24 |
| API key / token | 32 | 256 | 64 | 44 |
| AES-256 key | 32 | 256 | 64 | 44 |
| HMAC-SHA256 key | 32–64 | 256–512 | 64–128 | 44–88 |
| ChaCha20 nonce | 12 | 96 | 24 | 16 |
| Ed25519 private key | 32 | 256 | 64 | 44 |
Never reuse random bytes — A nonce or IV must be unique for every encryption operation with the same key. Reuse enables attacks like the AES-GCM nonce reuse attack, which can recover the authentication key and decrypt all messages. Always generate a fresh value per operation.
Do not store raw tokens — Store the SHA-256 hash of session tokens and API keys in your database, not the token itself. This ensures that even a full database leak cannot be used to impersonate users or make authenticated API calls.
Use sufficient length — 128 bits (16 bytes) is the minimum acceptable. For new systems, prefer 256 bits (32 bytes). Longer is not meaningfully more secure beyond 256 bits for symmetric cryptography but imposes no real cost.
Encode appropriately for your context — Hex is universally safe in URLs, headers, and file names. Base64 may require URL-safe encoding (+→-, /→_) in certain contexts. The uint8 format is for programmatic use in code, not for transmission.