Skip to main content
Back to Dev generators

Dev

Random Base64 String Generator

Used by developers, writers, and creators worldwide.

A random Base64 string generator gives developers cryptographically secure, encoded strings without writing boilerplate crypto code. Set the byte length to control entropy — 32 bytes yields 256 bits, the standard for HMAC-SHA256 JWT secrets and AES-256 keys; 16 bytes gives 128 bits for session nonces and CSRF tokens. For example, a 64-byte string works well as an HS512 signing key or a high-value API credential. Choose URL-safe mode to swap the standard `+` and `/` characters for `-` and `_`, making strings safe for query parameters, S3 keys, and JWT headers without percent-encoding. All output is generated client-side. Use the count field to batch dozens of strings at once for seed files or multi-service `.env` setups.

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 Byte Length field to the number of random bytes you need — 32 for JWT secrets, 16 for session tokens.
  2. Set How Many to the number of strings you want generated in one batch.
  3. Choose URL-Safe Base64 if the strings will appear in URLs, cookies, filenames, or JWT headers.
  4. Click Generate to produce the list of Base64-encoded strings.
  5. Click any string or use the copy button to grab it for your .env file, config, or test fixture.

Use Cases

  • •Generating 32-byte HMAC-SHA256 JWT signing secrets for Node.js Express or FastAPI apps
  • •Populating .env files with AES-256 encryption keys during local Docker Compose setup
  • •Seeding a Postgres fixture file with unique Base64 session tokens for 50 mock users
  • •Creating URL-safe refresh tokens for OAuth 2.0 flows tested in Postman or Insomnia
  • •Batch-generating API key values to populate a CI pipeline's GitHub Actions secret matrix

Tips

  • →For AES-256 keys, always use exactly 32 bytes — other lengths will require padding or truncation in most libraries.
  • →URL-safe mode is the safer default for new projects; it works everywhere standard Base64 works but avoids URL escaping bugs.
  • →Generate a fresh batch of 10 strings and keep them in a local scratch file as a reserve for spinning up new services quickly.
  • →Avoid reusing the same Base64 secret across environments — generate separate strings for dev, staging, and production.
  • →If your framework expects Base64 without padding, most URL-safe generators strip the trailing `=` — verify your library's expectations before use.
  • →When seeding test databases, use 16 bytes for token columns — it balances entropy with storage efficiency in VARCHAR fields.

FAQ

what byte length should i use for a jwt secret or api key

Use 32 bytes (256 bits) for HMAC-SHA256 (HS256) JWT signing — it matches the hash output size and is the widely accepted minimum. For HS512 or high-value API keys, go to 64 bytes. The resulting Base64 string will be 43 characters (32 bytes) or 86 characters (64 bytes) with padding stripped.

difference between standard and url-safe base64

Standard Base64 uses `+` and `/`, which are reserved characters in URLs and must be percent-encoded in query strings or cookies. URL-safe Base64 (RFC 4648 §5) replaces them with `-` and `_`, so the string works directly in JWTs, S3 object keys, filenames, and query parameters without extra escaping.

are these base64 strings safe to use as real secrets in production

The underlying bytes come from a cryptographically secure random source, so the entropy is production-grade. That said, store any generated secret immediately in a secrets manager like AWS Secrets Manager or HashiCorp Vault rather than leaving it in browser history or a plaintext file.