Laravel APP_KEY Generator

Generate a secure Laravel APP_KEY (base64: + 32 random bytes) ready to paste into your .env file.

APP_KEY

Generating key…

Security note

Never commit your .env file or APP_KEY to version control. Rotate the key immediately if it is ever exposed — doing so will invalidate all encrypted cookies and sessions. Generated locally — never transmitted.

What is the Laravel APP_KEY?

Laravel's APP_KEY is a 256-bit (32-byte) random value encoded as base64:.... It powers Laravel's encryption facilities (AES-256-CBC), signed cookies, encrypted session data, and the Crypt facade. Without a strong, unique key, encrypted values can be forged or decrypted by an attacker. Running php artisan key:generate does exactly what this tool does — generates 32 secure random bytes and base64-encodes them. This generator uses crypto.getRandomValues for the same level of cryptographic strength, directly in your browser.

Built and maintained by Meet Shah · Last updated 19 July 2026

What this tool is used for

Producing a key for a fresh application rather than leaving the placeholder.
Rotating a key after re-encrypting the data it protects, in that order.
Generating distinct keys per environment so encrypted values do not cross over.
Producing a key in the exact base64 form the config expects.
Setting a key on a host that was provisioned from an image with one baked in.

Frequently Asked Questions

What does Laravel use APP_KEY for?: Symmetric encryption and signing — encrypted cookies, the session payload, signed URLs, and anything through the `Crypt` facade. It is a 32-byte key for AES-256-CBC, which is why it must be exactly 32 random bytes rather than a passphrase.
Why is there a base64: prefix?: Because Laravel reads the prefix to decide whether to base64-decode the value or use it as raw bytes. Without it the framework treats the 44-character encoded string as the key itself — the wrong length — and throws "unsupported cipher or incorrect key length" at boot.
What happens if I change it on a live application?: Every existing encrypted value becomes undecryptable. All sessions are invalidated, users are logged out, signed URLs stop verifying, and any encrypted database column is lost unless you decrypt with the old key first. Rotating it is a migration, not a config change.
Where does the randomness come from?: `crypto.getRandomValues`, the browser's CSPRNG, seeded by the operating system. Not `Math.random`, which is a fast PRNG with no security guarantee and predictable output given enough samples — a distinction that matters exactly as much here as it looks like it should.
Should each environment have its own key?: Yes. Staging and production sharing a key means a staging compromise decrypts production sessions, and a key committed to the repository is public regardless of how private the repository is. Generate per environment, store in the environment, never in git.

Common errors and gotchas

Committing the key, which is the most common Laravel deployment mistake.
Rotating it without re-encrypting existing data, which makes every encrypted value unreadable.
Omitting the `base64:` prefix, which the framework needs to decode the key correctly.
Sharing one key across environments, so a staging leak decrypts production data.
Assuming it only affects sessions, when it also protects every encrypted column and cookie.