Environment Variable Generator
Create the configuration file for your app in a minute. Start from a template or an empty list, generate cryptographically strong secrets with one click, and export the result as a .env file, a safe .env.example, shell exports, Docker settings or JSON. Nothing you type leaves your browser.
- Runs in your browser
- No sign-up
- Free to use
Everything on this page stays in your browser. Secrets are created with the browser’s cryptographic random generator and are never transmitted or stored.
How to use Environment Variable Generator
- Choose a template for your framework, or start empty.
- Edit the names and values; press the key button to generate a secret.
- Select the output format.
- Copy or download the result and save it under the right file name.
Environment Variable Generator features
Strong secrets
Created with the browser's cryptographic random generator, at 128, 256 or 512 bits, in hex, Base64 or alphanumeric form.
Framework templates
Typical variables for Node.js, Laravel (including the APP_KEY format), Django and Next.js.
.env.example
Produces the version to commit: same variables, secret values and passwords in URLs removed.
Six output formats
.env, .env.example, shell export lines, a Docker Compose environment block, docker run flags and JSON.
Correct quoting
Values with spaces, quotes, # or $ are quoted so that dotenv libraries, shells and YAML read them unchanged.
Checks
Invalid and duplicate names, placeholder passwords, and secrets in variables that are exposed to browsers.
When to use Environment Variable Generator
- Setting up a new project or a new server.
- Generating SECRET_KEY, JWT_SECRET, APP_KEY or session secrets.
- Producing a .env.example to commit for the team.
- Converting configuration between a .env file and Docker or shell syntax.
Environment Variable Generator FAQ
Are the generated secrets really random?
Yes. They come from crypto.getRandomValues, the browser's cryptographically secure generator, the same source used for encryption keys. A 256-bit secret cannot be guessed by any feasible amount of computation.
Is anything sent to your server?
No. The page works entirely in your browser. Values are not transmitted, logged or saved, and they are gone when you close the tab. You can verify this by opening the network tab of your browser's developer tools, or by using the page offline once it has loaded.
What is the difference between .env and .env.example?
.env holds the real values, including secrets, and must never be committed. .env.example lists the same variables with harmless or empty values and is committed, so that anyone setting up the project knows what to configure.
Why are some values put in quotes?
An unquoted value ends at a space or at a # in many dotenv parsers, and $ may start variable substitution. Quoting makes the value literal. Simple values are left unquoted, which is how most files are written.
Can I change a secret later?
It depends on what it protects. Changing a session or JWT secret signs everyone out. Changing an encryption key, such as Laravel's APP_KEY, makes existing encrypted data unreadable. Generate such keys once per environment and store them safely.
Which variables are visible to browsers?
Front-end build tools embed variables with certain prefixes into the JavaScript bundle: NEXT_PUBLIC_ in Next.js, VITE_ in Vite, REACT_APP_ in Create React App. Anything there is public. The tool warns when a variable with such a prefix looks like a secret.
Configuration belongs in the environment
An application behaves differently on a laptop, a test server and in production: different database, different URLs, different keys. The code, however, should be identical. The established answer is to keep everything that varies between environments outside the code, in environment variables, a practice popularised by the Twelve-Factor App guidelines. The program reads its settings from the environment at start-up, and the same build runs anywhere.
A .env file is a convenience on top of that idea: a text file of NAME=value lines that a library loads into the environment when the app starts. It is ideal for development and for simple deployments. On hosting platforms and in container orchestrators, the variables are usually set in the platform's configuration or secret store, and no file exists at all.
Because these files hold credentials, their handling matters more than their format. The real file stays out of version control, listed in .gitignore, and out of container images. A secret that was ever committed must be considered exposed, since removing it from the latest commit does not remove it from history; the only fix is to replace the secret. Each environment gets its own values, so that a leak from a test system does not open production.
The quality of secrets matters too. Keys that sign sessions or tokens must be unpredictable: long, random and unique. Words, names and keyboard patterns can be guessed, and a guessed signing key lets an attacker forge any session. Generating secrets with a cryptographic random source, as this tool does, removes that risk. Front-end code is a special case: any variable compiled into a browser bundle is public by design, so secrets must stay on the server.