Your files never leave your device. All processing happens locally in your browser.
How do I generate cryptographically secure random bytes?
Choose a size (1–1024 bytes, or a preset like 16 for a 128-bit key, 32 for a 256-bit key, 12 for an AES-GCM IV) and this tool draws the bytes from window.crypto.getRandomValues — your browser’s cryptographically secure PRNG, never Math.random. Read them as hex, base64, base64url, a UUID v4 and more, each copyable. Everything runs locally; nothing is uploaded.
Randomness from window.crypto.getRandomValues (a CSPRNG), never Math.random
Password/token helper uses unbiased rejection sampling with a live entropy read-out
100% client-side — nothing uploaded, nothing stored; reload and the keys are gone
What is
CSPRNG (Cryptographically Secure Pseudo-Random Number Generator)
A CSPRNG is a random number generator whose output is unpredictable enough for cryptographic use: even knowing every previous bit, an attacker cannot guess the next one better than chance. In the browser it is exposed as window.crypto.getRandomValues, seeded from operating-system and hardware entropy — the correct source for keys, IVs, salts, nonces and tokens. It is fundamentally different from Math.random, a fast but predictable PRNG that must never be used for secrets. This tool draws every byte from the CSPRNG entirely on your device.
No. Every byte is generated in your browser with crypto.getRandomValues and is never uploaded, logged or stored.
The tool is 100% client-side. When you pick a size, the bytes are drawn locally from <code>window.crypto.getRandomValues</code> — there is no network request, no upload, no logging, no server and no CDN in the generation path. The values exist only in your tab’s memory; reload the page and they are gone forever, with no history kept. The only optional network use anywhere on the site is consent-gated ads, which never see your output. Because the randomness is produced where you are, you never have to trust a remote server not to keep a copy of your key.
Yes for generation — it is a CSPRNG, the same quality as openssl rand — but store long-lived keys in a real KMS, not a web page.
<code>crypto.getRandomValues</code> is a cryptographically secure PRNG seeded from OS and hardware entropy, so the bytes it produces are suitable for AES keys, IVs, salts, nonces and tokens — the same class of randomness as <code>openssl rand</code>. The honest caveats are about everything AROUND the draw: the Web Crypto spec sets no minimum-entropy guarantee and a web page cannot audit the browser’s RNG, and a key is only as safe as where it ends up. For the highest-stakes, long-lived production secrets, generate and store them in a hardware token or a real KMS / secrets manager (AWS KMS, GCP KMS, HashiCorp Vault) rather than copying from any web page.
A 256-bit key is 32 bytes, a 128-bit key or salt is 16 bytes, and an AES-GCM IV is 12 bytes; the tool has presets for each.
Bit strength equals bytes × 8, so 16 bytes is 128-bit (AES-128 or a salt), 32 bytes is 256-bit (AES-256 or a session token) and 64 bytes is 512-bit (an HMAC-SHA512 key). For an initialization vector the size is defined by the mode: AES-GCM recommends a 12-byte (96-bit) IV, while CBC-style modes use a 16-byte IV matching the block size. A salt for password hashing is commonly 16 bytes. The tool ships presets for 12, 16, 24, 32 and 64 bytes and shows the bit strength and typical use for whatever size you choose.
It uses rejection sampling: a random byte is only accepted below the largest multiple of the pool size that fits in 256, otherwise it is re-rolled.
Mapping a random byte to a character pool with a naive <code>byte % N</code> introduces modulo bias — because 256 is rarely an exact multiple of the pool size, the first few characters come up slightly more often. This tool instead uses rejection sampling: for a pool of size N it computes the threshold <code>256 − (256 mod N)</code> and accepts a random byte only when it is below that threshold, re-rolling otherwise. The result is a uniform distribution where every character is equally likely, drawn from <code>crypto.getRandomValues</code>. A live entropy read-out (length × log₂(pool size), in bits) shows the resulting strength so you can target 80+ bits for accounts or 128+ for master secrets.
Detailed Explanation
📖How It Works
What the Random Bytes Generator Does
The Random Bytes Generator is a 100% client-side tool that produces cryptographically secure random bytes and tokens for keys, initialization vectors, salts, nonces and API tokens. The user chooses a size from 1 to 1024 bytes — with labelled presets such as 12 bytes for an AES-GCM IV, 16 bytes for a 128-bit key or salt, 32 bytes for a 256-bit key and 64 bytes for an HMAC-SHA512 key — and reads the result in eleven copyable formats. All randomness comes from window.crypto.getRandomValues, the browser’s cryptographically secure PRNG, and nothing is ever uploaded.
Size 1–1024 bytes with key / IV / salt / nonce presets
Randomness from window.crypto.getRandomValues (a CSPRNG), never Math.random
Eleven output formats, each copyable, plus a download-all-as-text option
A separate password/token helper with unbiased rejection sampling
Bit strength shown live (bytes × 8) with the typical use for each size
⚙️Methodology
How the Randomness Is Produced
Bytes are drawn directly from window.crypto.getRandomValues, which the browser backs with the operating system’s cryptographically secure entropy source (for example /dev/urandom or CryptGenRandom), seeded from hardware and OS noise. Because the API throws a QuotaExceededError above 65 536 bytes per call, larger requests are filled in chunks. The UUID v4 output follows RFC 4122 §4.4: sixteen random bytes are taken and the version and variant bits are stamped — byte 6 becomes (b & 0x0f) | 0x40 and byte 8 becomes (b & 0x3f) | 0x80 — leaving 122 random bits. The password helper maps random bytes to characters with rejection sampling so there is no modulo bias.
Entropy source: OS CSPRNG via window.crypto.getRandomValues
Requests above the 65 536-byte per-call quota are filled in chunks
UUID v4 stamps version (0x40) and variant (0x80) bits per RFC 4122
Rejection sampling threshold is 256 − (256 mod poolSize)
No Math.random anywhere in the generation path
📋Use Cases
Choosing the Right Size
Bit strength equals the byte count times eight, so the size you pick maps directly to a security level. Sixteen bytes is 128-bit (AES-128, or a salt); 32 bytes is 256-bit (AES-256, or a session token); 64 bytes is 512-bit (an HMAC-SHA512 key). Initialization-vector size is set by the cipher mode: AES-GCM recommends a 12-byte (96-bit) IV, while CBC-style modes use a 16-byte IV matching the block size. Salts for password hashing are commonly 16 bytes. The tool labels each preset with its purpose and shows the resulting bit strength so the choice is explicit.
16-byte IV matches the AES block size for CBC-style modes
64 bytes = 512-bit, sized for an HMAC-SHA512 key
Every IV / nonce must be unique per message under a given key
⚠️Limitations
Honest Limitations
crypto.getRandomValues is a CSPRNG suitable for keys, IVs, salts, nonces and tokens — the same quality as openssl rand — and is categorically not Math.random, which is predictable and must never be used for secrets. The honest caveats concern everything around the draw: the Web Cryptography spec sets no minimum-entropy guarantee and a web page cannot audit the browser’s RNG implementation; a generated key is only as safe as where it is stored afterwards, so pasting one into a chat, a commit, a screenshot or an unencrypted note is the real risk; and an IV or nonce must be unique per message, which the tool provides but cannot enforce. For long-lived production secrets, generate and store keys in a real KMS or secrets manager rather than copying from any web page.
CSPRNG-quality randomness, but no spec-mandated minimum entropy
A web page cannot audit the browser’s RNG implementation
The storage of the secret, not the draw, is usually the real risk
For long-lived keys prefer a hardware token or a KMS / secrets manager
The tool cannot enforce IV / nonce uniqueness across your messages
🔒Privacy & Security
Private by Design
Everything happens on your device. The bytes are generated by the browser’s own CSPRNG and the formatting is pure local JavaScript — there is no network request, no upload, no logging, no server and no CDN in the generation path. Nothing is persisted or added to history; reload the page and the values are gone. The tool works offline once cached, and the only optional network use anywhere on the site is consent-gated ads, which never see your output. This matters because random bytes are frequently the seed of a real secret — an encryption key, an API token, a signing key — that you would never want to round-trip through a remote server.
Bytes generated locally by the browser CSPRNG — nothing uploaded
No server, no CDN, no logging, no telemetry, no account
Nothing persisted; values vanish on reload
Works offline once cached; dark-mode and mobile-first
Keeps your keys, tokens and salts entirely on your machine
Random sources for cryptographic material
Source
Cryptographically secure?
Best for
Notes
window.crypto.getRandomValues
Yes (CSPRNG)
Keys, IVs, salts, nonces, tokens in the browser
What this tool uses; 65 536-byte per-call quota, filled in chunks
Math.random
No
Non-security jitter, animations, sampling
Predictable — must never be used for secrets
openssl rand
Yes (CSPRNG)
Keys and tokens from the command line
Same class of randomness; this tool is the in-browser equivalent
crypto.subtle.generateKey
Yes
Producing a live CryptoKey for Web Crypto
Preferred when you need a key object, not raw bytes
KMS / secrets manager
Yes
Long-lived production keys
Adds managed storage, rotation and access control the browser cannot
crypto.getRandomValues is suitable for generating keys and tokens; for storing long-lived production secrets use a real KMS. Everything in this tool runs locally in the browser; nothing is uploaded. As of July 2026.
