1001Ferramentas
🔢Generators

Random Bytes Generator

Generate random bytes in hex, base64 or binary — using browser crypto.getRandomValues. For cryptographically secure keys, salts and tokens.


  

Random bytes — the foundational building block of cryptography

Almost every cryptographic operation begins with a chunk of random bytes: symmetric keys, salts, nonces, initialization vectors, session tokens, magic links, password reset codes and TLS handshakes all depend on the quality of the randomness underneath them. The output of this tool comes from a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator), the only family of generators safe to use for security-sensitive purposes. The exact source depends on the runtime: crypto.getRandomValues from the Web Crypto API in browsers, crypto.randomBytes in Node.js, secrets.token_bytes in Python, java.security.SecureRandom in Java, OS_genrandom through libsodium and /dev/urandom on Linux/Unix. All of them eventually pull from the operating system's entropy pool — the same pool that seeds the kernel's RNG with hardware events, RDRAND, interrupt timing and other unpredictable sources.

It is critical to understand that Math.random() is not a CSPRNG. Browser implementations historically used algorithms like xorshift128+ and only provide around 52 bits of float entropy with detectable bias — fine for animations and game dice, catastrophic for crypto. The historical advice to read /dev/random (blocking) instead of /dev/urandom is no longer correct on modern Linux kernels: once the pool is seeded at boot, both produce equally strong output. NIST SP 800-90A and 800-90B are the reference standards describing approved CSPRNG constructions (CTR_DRBG, HMAC_DRBG, Hash_DRBG).

Encodings — hex, base64, base64url and friends

Random bytes are binary; humans and protocols usually need a text representation. The most common encodings are:

  • hex — 2 characters per byte, alphabet 0-9a-f, case-insensitive. Easy to copy by eye and to diff. 100% overhead. Example: 0a1b2c3d.
  • base64 — 4 characters per 3 bytes (~33% overhead), alphabet A-Za-z0-9+/ with = padding. Standard in MIME, JWT payloads and PEM files.
  • base64url — RFC 4648 §5 variant: + becomes -, / becomes _, padding usually dropped. Safe to drop into URLs, cookies and filenames without escaping. Used by JWT headers and signatures.
  • base32 — 5 bits per character, RFC 4648 §6. Case-insensitive and free of look-alike pairs. Used by TOTP keys, Tor onion v3 addresses and some QR formats.
  • base58 — Bitcoin/IPFS alphabet that excludes the visually ambiguous 0, O, I and l characters.

How many bytes is enough?

Entropy is measured in bits. Each byte contributes 8 bits, so 16 bytes = 128 bits and 32 bytes = 256 bits. Rough rules of thumb in 2026:

  • 128 bits (16 bytes) — modern minimum for AES-128 keys, bcrypt salts, session cookies, CSRF tokens, password reset links.
  • 192 bits (24 bytes) — AES-192 keys, conservative tokens.
  • 256 bits (32 bytes) — AES-256, HMAC-SHA256 keys, long-lived API tokens, anything where a 2^128 brute force budget feels too close.
  • 12 bytes — typical GCM nonce/IV size.
  • 16 bytes — typical CBC IV.

Common pitfalls

  • Reusing an IV/nonce with the same key in CTR/GCM breaks confidentiality and (for GCM) destroys integrity — always generate a fresh random nonce per encryption.
  • Freshly booted VMs and containers used to ship with empty entropy pools — modern kernels mitigate this with RDRAND/jitter, but very old AMI snapshots can still be problematic.
  • Truncating a 32-byte hex string to "look prettier" cuts the security level in half for every byte removed.
  • Never seed a CSPRNG yourself from Date.now() or the user agent — let the OS handle it.

FAQ

How do I know a function is a CSPRNG? If it lives in the crypto/secrets module of your language's standard library, it is. If it lives in Math, random, rand() or anything ending in _r, it is not — those are deterministic PRNGs meant for simulation.

Should I pick hex or base64? Pick hex when humans will read or transcribe the value. Pick base64url when the value goes into a URL, cookie, JSON field or filename — it is 25% shorter and still URL-safe.

Is 16 bytes really enough for a session token? Yes. 128 bits of true randomness is more than the working memory of the entire planet combined for the next several decades. If your threat model includes a nation-state with quantum hardware in 2050, bump to 32 bytes.

Does this tool send my bytes to the server? No. The bytes are generated entirely in your browser through window.crypto.getRandomValues — nothing leaves your device.

Related Tools