Secret Key Generator
Every web framework needs a secret key, and each expects a particular format. Pick your framework or purpose and get a correctly formatted, cryptographically random key ready to paste into your .env file or configuration: Laravel’s base64-prefixed APP_KEY, Django’s 50-character key, Rails’ 128-character secret_key_base, a JWT signing secret, AES keys with an IV, or all eight WordPress salts.
- Runs in your browser
- No sign-up
- Free to use
Generated in your browser and never sent or stored. Put the value in your environment or secret store, not in source control.
How to use Secret Key Generator
- Choose the framework or kind of key.
- Read what the format is and why.
- Copy the line into your environment file or secret store.
- Restart the application so it uses the new key.
Secret Key Generator features
Framework formats
Laravel, Django, Flask, Rails, Auth.js, Fernet and WordPress.
Cryptographic keys
AES-128 and AES-256 keys with IVs in hex.
JWT secrets
256-bit HS256 secrets in Base64URL.
Ready to paste
Lines in .env or PHP define() format.
Explained
Each format comes with a short description.
Private
Generated in the browser; never sent or stored.
When to use Secret Key Generator
- Setting up a new Laravel, Django or Rails project.
- Rotating a secret that may have leaked.
- Creating WordPress salts after a security incident.
- Generating a JWT secret for an authentication service.
Secret Key Generator FAQ
What happens when I change an application secret?
It depends on the framework. Usually sessions become invalid and users must log in again; data encrypted with the old key, such as Laravel encrypted values, can no longer be decrypted. Plan rotations accordingly.
Is it safe to generate keys in a browser?
The randomness comes from the browser’s cryptographic generator. The risk is exposure: anyone who sees your screen or clipboard sees the key. For production, many teams prefer the framework’s own command on the server.
Where should the key be stored?
In environment variables or a secret manager, never in source control. Make sure .env files are excluded from Git.
Why does Laravel’s key start with “base64:”?
Laravel needs 32 raw bytes for AES-256. The prefix tells it the rest is Base64-encoded bytes rather than a literal string.
Can I reuse an IV?
Never with the same key for different messages. Generate a new IV or nonce for every encryption; only the key stays fixed.
Why are WordPress salts so long?
They are hashed into cookies and nonces; longer random strings make those values unpredictable.
The key that protects everything else
Most web applications have one master secret. It signs session cookies, encrypts data, generates password-reset tokens and protects forms against forgery. If it leaks, an attacker can forge sessions and decrypt data; if it is weak, they can guess it. Generating it properly is one of the first steps of any deployment.
Frameworks differ in format. Laravel wants 32 bytes for AES-256, written as Base64 with a prefix. Django uses a 50-character string from a specific alphabet. Rails uses 64 bytes in hexadecimal. Fernet keys are URL-safe Base64. The underlying requirement is the same: enough cryptographic randomness, typically 256 bits.
Treat the key like a password with more power. Keep it out of source code and version control, give each environment its own key, and restrict who can read production configuration. If a key is exposed, rotate it promptly and understand what the rotation invalidates.
Symmetric encryption keys deserve extra care. Use authenticated modes such as AES-GCM, generate a fresh nonce for each message, and prefer well-reviewed libraries over hand-written cryptography. The generator gives you the random material; the library should do the rest.