Create a .env file in seconds. Pick a framework template, add variables, generate secure random secrets, and copy or download a ready-made .env example.
This .env file generator builds a valid environment file from scratch or from a framework template, so you can stop copying a half-remembered .env.example out of an old project. Pick the stacks and services you use, fill in the values, generate cryptographically random secrets where you need them, and copy or download the finished file. Everything happens in your browser — no keys are transmitted, logged or stored, which is the only acceptable arrangement for a file whose entire job is holding credentials.
It also works in reverse: upload an existing .env and the tool parses it into an editable list, flagging entries whose names look like secrets (SECRET, PASSWORD, KEY, TOKEN, PRIVATE, CREDENTIAL) so you can strip the values and turn a working file into a shareable example in one pass.
A .env file is a flat list of KEY=value lines that your application loads into its process environment at startup. It exists to keep configuration — and especially secrets — out of source code, so the same codebase can run in development, staging and production with different database URLs, API keys and feature flags. The convention comes from the twelve-factor app methodology and is implemented by dotenv and its ports in virtually every language.
A minimal, realistic example:
# Database
DATABASE_URL=postgresql://user:password@localhost:5432/mydb
# Authentication
JWT_SECRET=Xn7Qw2LpR8vTz4KmA1BcE6HdF9GjS3Yu
SESSION_TIMEOUT=3600
# Third-party API (required)
API_TOKEN=your_api_token_here
STRIPE_SECRET_KEY=sk_test_placeholder
# App
NODE_ENV=development
PORT=3000
DEBUG=false
The syntax rules are simple but unforgiving. One assignment per line. No spaces around the =. Lines starting with # are comments. Values containing spaces, #, or quote characters must be wrapped in double quotes with inner quotes escaped — the generator applies that quoting automatically, which removes the most common source of “the variable loaded but the value is truncated” bugs. Values are always strings: DEBUG=false arrives in your code as the string "false", which is truthy in JavaScript and Python alike, so parse booleans explicitly.
These names describe the same format serving two opposite purposes, and conflating them is how credentials end up on GitHub.
.env holds real values for one machine. It is added to .gitignore and never committed..env.example (also seen as .env.template or .env.sample) holds the same keys with placeholder values, and is committed. It documents which variables the app needs so a new developer can copy it to .env and fill in the blanks.To produce the example file here, build or upload your variable list, replace each sensitive value with a placeholder such as your_api_token_here or sk_test_xxx, keep the descriptions turned on so each key carries an explanatory comment, and save the output as .env.example. Add .env, .env.local and .env.*.local to .gitignore before the first commit, not after — once a secret is in git history, rotating the credential is the only real fix.
Select one or more templates and their variables merge into a single file with the correct names and sensible defaults already in place. Covered stacks and services include Next.js, Express.js, Django, FastAPI, Ruby on Rails, Laravel and Docker Compose, alongside AWS, Stripe, Auth0, Firebase, SendGrid, Supabase, PlanetScale, Vercel and OpenAI. Combining, say, Next.js with Stripe and Supabase gives you the exact set of keys those three expect — including the framework-specific prefixes that decide whether a value is exposed to the browser.
That last point deserves emphasis. In Next.js, any variable prefixed NEXT_PUBLIC_ is inlined into the client bundle at build time and is readable by anyone who opens DevTools. The equivalents are VITE_ in Vite, REACT_APP_ in Create React App and PUBLIC_ in SvelteKit. Never give a secret one of these prefixes. A publishable Stripe key belongs there; a secret key never does.
Every value field has a generate button that produces a 32-character random string drawn from crypto.getRandomValues — the browser's cryptographically secure random source, not Math.random(). Over a 62-character alphabet, 32 characters carry roughly 190 bits of entropy, comfortably beyond what any session-signing or JWT secret requires. Use it for JWT_SECRET, SESSION_SECRET, ENCRYPTION_KEY, webhook signing secrets and anything else you would otherwise invent by mashing the keyboard. Generate a distinct value per environment: sharing one secret between staging and production means a staging compromise is a production compromise. For passwords with specific character-class rules, the secure password generator gives you finer control, and the entropy analyzer will tell you how strong an existing value actually is.
.env in your project root — and add it to .gitignore..env.example.Plain text, one KEY=value per line, uppercase keys with underscores, # for comments, no spaces around the equals sign, and quotes only around values that contain spaces or special characters. There is no JSON, YAML or indentation involved.
Yes. No account, no limits, and no server involved — the file is built in your browser.
Pick a template or add variables manually here, then copy or download the result and save it as .env in your project root. On the command line, the file name begins with a dot, so use touch .env on macOS and Linux, or New-Item .env in PowerShell — Windows Explorer resists creating dot-files directly.
.env contains real credentials and is git-ignored. .env.example contains the same keys with placeholder values and is committed, so teammates know what to configure. Generate both here from one variable list.
Keep the key and replace the value with an obviously fake string that hints at the format — API_TOKEN=your_api_token_here, STRIPE_SECRET_KEY=sk_test_xxxxxxxxxxxx. Never leave a real token in a committed example, and never use a value that could be mistaken for a working one.
No. Generation, parsing and secret creation all run client-side. Nothing you type is uploaded, and uploaded files are read in the browser only.
No. Add .env, .env.local and .env.*.local to .gitignore. If a secret has already been committed, treat it as compromised: rotate the credential first, then clean the history.
Only when the value contains a space, a #, or quote characters — then wrap it in double quotes. The generator adds that quoting for you and escapes embedded quotes. Unnecessary quotes are usually harmless but some parsers include them in the value.
Any variable carrying a client-side prefix: NEXT_PUBLIC_ in Next.js, VITE_ in Vite, REACT_APP_ in Create React App, PUBLIC_ in SvelteKit. These are compiled into the JavaScript bundle and are fully readable by users, so only publishable values belong there.
Yes. Upload it and the tool parses each line into an editable row, automatically marking keys that contain SECRET, PASSWORD, KEY, TOKEN, PRIVATE or CREDENTIAL as secrets so you can clear them before exporting an example file.
Environment files (.env files) store configuration variables that differ between deployment environments — development, staging, and production. Instead of hardcoding database URLs, API keys, port numbers, and feature flags in source code, applications read these values from environment variables at runtime. The .env file format, popularized by the Twelve-Factor App methodology, provides a simple key-value format that development tools like Docker Compose, Node.js (via dotenv), Python (via python-dotenv), and most modern frameworks automatically load.
This tool generates properly structured .env files with common variables for various application stacks, including placeholder values and documentation comments.
# Database Configuration
DATABASE_URL=postgresql://user:password@localhost:5432/mydb
DATABASE_POOL_SIZE=10
# API Keys
STRIPE_SECRET_KEY=sk_test_...
STRIPE_PUBLISHABLE_KEY=pk_test_...
# Application Settings
NODE_ENV=development
PORT=3000
LOG_LEVEL=debug
# Feature Flags
ENABLE_NEW_DASHBOARD=false
| Rule | Correct | Incorrect |
|---|---|---|
| No spaces around = | DATABASE_URL=value | DATABASE_URL = value |
| Quote values with spaces | APP_NAME="My App" | APP_NAME=My App |
| Comments start with # | # This is a comment | // This is a comment |
| No export prefix (usually) | KEY=value | export KEY=value |
| Blank lines are ignored | (blank line) | N/A |
Never commit .env files containing secrets. Add .env* to .gitignore. Instead, commit a .env.example with placeholder values showing required variables. Use secret management services in production (AWS Secrets Manager, HashiCorp Vault, Doppler).
.env contains defaults for all environments. .env.local overrides for local development and should not be committed. .env.production and .env.development provide environment-specific values. Most frameworks load these in a specific precedence order.
Use cryptographically secure random generators: openssl rand -base64 32, python -c using secrets.token_urlsafe(32), or node -e using crypto.randomBytes(32).toString(base64)
In Next.js, variables prefixed with NEXT_PUBLIC_ are exposed to the browser. Without this prefix, variables are only available server-side. Never put secrets in NEXT_PUBLIC_ variables as they will be bundled into client-side JavaScript.