Skip to main content
Back to Numbers generators

Numbers

Random Bytes Hex Generator

Used by developers, writers, and creators worldwide.

A random bytes hex generator lets you produce hex-encoded byte strings for tokens, keys, salts, and nonces without writing any code. Each output mirrors what you'd get from Node.js crypto.randomBytes() or Python's os.urandom() — two hex characters per byte, so 16 bytes gives you a 32-character string carrying 128 bits of entropy. That's enough for most session tokens and CSRF values. Need 256-bit strength for an API secret or JWT signing key? Switch to 32 bytes. You can generate up to a batch at a time, choose your byte length, and control how individual bytes appear: no separator for copy-paste-ready strings, colon-separated for TLS fingerprint style, or dash-separated for readability in logs and docs.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  1. Set the 'Number of bytes' field to your target length — 16 for 128-bit tokens, 32 for 256-bit secrets.
  2. Set 'How many' to the number of unique hex strings you need in a single batch.
  3. Choose a separator: none for raw code-ready strings, colon for MAC-style readability, or space for easy visual scanning.
  4. Click Generate to produce the batch of random hex byte strings.
  5. Click any result to copy it, or copy all strings at once to paste into your code, config file, or test fixture.

Use Cases

  • •Generating 32-byte JWT signing secrets to paste into a .env file during local API development
  • •Producing colon-separated 16-byte values to mock TLS certificate fingerprints in Postman test scripts
  • •Creating 64-byte salts for Argon2 password hashing in a Node.js authentication service
  • •Bulk-generating 20 unique 16-byte request IDs to seed distributed tracing fixtures in a Jest test suite
  • •Producing 12-byte AES-GCM nonces to populate cipher test vectors in a Go cryptography unit test

Tips

  • →Generate 5-10 strings at once when testing, then discard all but one — variety reduces accidental reuse in test fixtures.
  • →For bcrypt salts, 16 bytes is sufficient; Argon2id recommends at least 16 bytes but 32 is safer for long-term storage.
  • →Colon-separated output can be pasted directly into Wireshark filters or network documentation without reformatting.
  • →If your framework expects a base64-encoded secret rather than hex, generate 32 hex bytes then convert: the entropy is the same.
  • →Never log or commit generated values — even test tokens become attack vectors if they reach version control or production logs.
  • →Pair 12-byte output with AES-GCM nonces; pairing the wrong size nonce with a cipher is a common and silent cryptographic mistake.

FAQ

is the output from this random bytes hex generator safe to use in production

No. This tool runs in the browser using Math.random(), which is not a cryptographically secure PRNG and should never be used for real secrets. For production keys, tokens, and salts use crypto.randomBytes() in Node.js, os.urandom() in Python, or your platform's hardware-backed CSPRNG. This generator is best suited for prototyping, test fixtures, and documentation examples.

how many hex characters does a given byte length produce

Every byte encodes to exactly two hex characters, so the output length in characters is always twice the byte count. Sixteen bytes gives 32 characters, 32 bytes gives 64, and 64 bytes gives 128. If you choose a separator like colon or dash, each separator adds one character between every pair of bytes, making the total string longer.

what byte length should I use for different secrets like api keys or nonces

For API keys and HMAC secrets, 32 bytes (256 bits) is the OWASP-recommended minimum — enough entropy to make brute-force infeasible. Session tokens and CSRF values are fine at 16 bytes (128 bits). AES-GCM nonces should be exactly 12 bytes. When in doubt, 32 bytes covers most modern security requirements.