.env · create🔥 popular

Secret Generator

Generate a random JWT secret, session secret, or API key instantly. Cryptographically strong secrets for .env files. 100% client-side.

Be the first to rate

generated locally with crypto.getRandomValues

JWT Secret (base64url, 48 bytes)

NextAuth, JWT, NEXTAUTH_SECRET

JWT Secret (base64url, 64 bytes)

HS512 / maximum entropy

API Key (hex, 16 bytes)

Short API tokens

API Key (hex, 32 bytes)

Standard API tokens

Session Secret (base64url, 32 bytes)

Express sessions, CSRF

Password (20 chars, symbols)

DB passwords, admin accounts

Password (32 chars, symbols)

High-security accounts

Password (16 chars, no symbols)

Shell-safe, URL-safe

What it does

▸JWT secrets (base64url, 48+ bytes)
▸Hex-encoded API keys and session tokens
▸Human-safe passwords with configurable charset
▸Uses browser crypto.getRandomValues — nothing leaves your machine
▸One-click copy

Privacy

Runs 100% in your browser. Your .env never touches our servers.

client-side only

Usage examples

Case 1 · JWT secret (base64url)

preset: JWT (48 bytes, base64url)

V8dG3mSvDk2xR6Lq9JjYwP3fNcKzHa_X5tUe7bM1pQs4rYvTi0oFgB_cE8AyWzLx

Case 2 · API key (hex)

preset: API key (32 bytes, hex)

a3f1c9d8e4b7a2f6c1d8e4b7a2f6c1d8e4b7a2f6c1d8e4b7a2f6c1d8e4b7a2f6

Case 3 · Human password

preset: password (20 chars, symbols)

x7$Kp!qW2@mR8hLn&dV

When to use this tool

→Rotating JWT_SECRET / NEXTAUTH_SECRET after a suspected leak
→Bootstrapping a new project that needs session/CSRF secrets
→Generating a database password for a new service account
→Creating an internal API token with strong entropy
→Replacing hand-typed secrets in a legacy .env

Common mistakes

⚠Regenerating a secret in prod without updating every service that depends on it (sessions will invalidate)
⚠Using a 16-byte secret where the spec needs 32+ (e.g. HS512 JWTs)
⚠Trusting the generated password for critical accounts without also enabling 2FA
⚠Keeping the generated value in browser history or sharing screenshots

Random Secret Generator

Generate cryptographically strong secrets with crypto.getRandomValues — the same primitive Node.js, Django, and Rails use internally. Perfect for JWT_SECRET, NEXTAUTH_SECRET, SESSION_SECRET, APP_KEY, and API tokens.

Why not just mash the keyboard?

Because predictable secrets get brute-forced. JWTs signed with a weak secret can be cracked in minutes. Every secret this tool produces has full 256-bit entropy (or more) and is generated locally in your browser — never sent or logged.

Frequently asked questions

How is the randomness generated?

Using crypto.getRandomValues — the browser's CSPRNG, backed by the OS entropy pool (/dev/urandom on Linux/macOS, BCryptGenRandom on Windows). This is the same source used by OpenSSL, Node's crypto module, and Python's secrets module.

Is there a difference between hex and base64 secrets?

Both are equally random for the same byte count — the difference is encoding, not entropy. Hex is shell-safe and URL-safe with no special characters. Base64 is 33% shorter but may contain +, /, and = which need quoting in .env files.

What length should I choose?

32 bytes (256 bits) is the minimum for HMAC signing keys and general-purpose secrets. Use 16 bytes for AES-128 keys or RAILS_MASTER_KEY. Use 48–64 bytes for HS384/HS512 JWT secrets or maximum-entropy API tokens.

Is it safe to use these secrets in production?

Yes. The generator uses the same CSPRNG as production cryptographic libraries. The only caveat: treat the generated value as a secret immediately — do not paste it into Slack, a ticket, or a public terminal window.