How are the secrets generated?

Via the browser's crypto.getRandomValues() API, which uses the OS's cryptographically-secure random number generator (CSPRNG). Output is base64-encoded for ASCII safety. The result is suitable for production secrets — same quality as `openssl rand -base64 32` from your terminal.

What's the difference between .env and .env.example?

.env contains REAL values (secrets, production credentials) and should be gitignored. .env.example contains the SAME KEYS with placeholder values and IS committed to the repo. New developers clone the repo, see .env.example, copy it to .env, and fill in real values from your secret manager. The example documents what's needed without leaking secrets.

Should I quote values?

Generally no for simple values: `DB_HOST=localhost`. Quote when value contains spaces or special characters: `DB_PASSWORD="my secret with spaces"` or `MESSAGE='Hello, World!'`. Single quotes preserve literally; double quotes allow escape sequences. Be aware: different dotenv parsers handle quoting slightly differently — test your specific library.

What's the JWT_SECRET supposed to look like?

A long random string — at least 256 bits (32 bytes) for HMAC signing. The standard recommendation is 64 bytes (512 bits) for HS512 or RS-family. Format: typically base64-encoded. Example: `JWT_SECRET=7K8mQpV3rN9wXdJ4lH6tY2sBuFcPaEz5oI1vM9nT0qWxAk=`. Don't hand-write this; the generator produces cryptographically-secure values.

Can I use the same .env across dev / staging / prod?

No. Each environment should have its own .env (or equivalent secret config) with values appropriate to that environment. dev: usually local/test resources, dummy keys. staging: real-but-isolated resources. prod: real production secrets. Same KEY names, different VALUES. .env.example documents the keys.

What about Docker / Kubernetes?

Docker: pass with `docker run --env-file .env image` or in docker-compose.yml. Kubernetes: convert to a ConfigMap (for non-secret values) or Secret (for sensitive values) using `kubectl create secret generic myapp --from-env-file=.env`. Both will read the same .env format.

Developer Utilities · Free tool

Dotenv Generator

Turn a VAR=value list into a .env file with 32-hex secrets and duplicate detection online. Get instant, free results in seconds with no sign-up.

Updated June 2026

VAR=value (one per line)

Warnings

L4infoEmpty value for "JWT_SECRET" — consider generating a secret.

Validated .env — 6 entries

NODE_ENV=production
PORT=3000
DATABASE_URL=postgres://user:pass@localhost:5432/db
JWT_SECRET=
APP_NAME="My Awesome App"
FEATURE_FLAG=true

Found this useful?Email Buy Me a Coffee

What it does

List the environment variables your app needs and the tool produces a clean .env file with auto- generated secrets, duplicate-key warnings, and consistent formatting. Useful for spinning up a new project with a plausible .env.example template, generating secrets like JWT signing keys / API tokens / database passwords (cryptographically random, ready to paste), auditing existing .env files for duplicates or formatting issues, and generating .env.example files to commit alongside your real .env (which should always be gitignored).

The dotenv format dates to 2010 (the dotenv Ruby gem by Brandon Keepers) and was popularized in Node.js by Scott Motte in 2013. The format is dead simple: KEY=value, one per line, optional comments with #, optional empty lines for grouping. The simplicity is the point — it works in every language (dotenv, python-dotenv, godotenv, dotenv.net, etc.) and plays nicely with Docker (--env-file), systemd (EnvironmentFile=), Kubernetes ConfigMaps, and CI/CD secret management.

The secret generator uses crypto.getRandomValues() — the browser’s cryptographically-secure random source. So the secrets you get are suitable for actual production use (JWT signing keys, session secrets, API tokens), not just examples. Default secret length is 32 bytes (256 bits) which is the standard for symmetric secrets in modern systems. Adjust as needed: 16 bytes for short tokens, 64 bytes for paranoid use.

Embed this tool on your siteShow snippet

Paste this snippet into any page. Loads on-demand (lazy), no tracking scripts, and sized to most dashboards. Replace the height to fit your layout.

<iframe src="https://freetoolarena.com/embed/dotenv-generator" width="100%" height="720" frameborder="0" loading="lazy" title="Dotenv Generator" style="border:1px solid #e2e8f0;border-radius:12px;max-width:720px;"></iframe>

Embed docs →

How to use it

List your environment variables one per line. Format: KEY=value or just KEY (the tool fills value).
For variables that need secrets (JWT_SECRET, SESSION_SECRET, DATABASE_PASSWORD, API_KEY), leave the value blank or write 'GENERATE' — the tool produces a cryptographically-random value.
Add comments with `#` for documentation: `# Database connection - production`, then list DB_HOST, DB_PORT, DB_USER, DB_PASS underneath.
Read the output: a formatted .env file with consistent spacing, secrets filled, duplicate warnings flagged.
Copy and save to your project root as `.env` (gitignored) AND `.env.example` (committed, with secret values redacted to `your-secret-here`).

When to use this tool

Spinning up a new project from scratch.
Generating production secrets (JWT keys, session secrets, API tokens).
Creating .env.example for committing alongside an actual .env.
Auditing an existing .env for duplicates or formatting issues.

When not to use it

Production secret management — use a real secret manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Doppler, 1Password Secrets Automation). .env files in production are a smell.
Storing secrets you'll commit — never commit .env to git. Use .env.example with placeholder values for committed templates.
Multi-environment management at scale — manual .env per environment doesn't scale. Use Doppler, Infisical, or your platform's secret manager.
Sharing secrets with teammates — don't email or Slack .env files. Use 1Password, Bitwarden, or Doppler shared vaults.

Common use cases

Pre-decision sanity-check on inputs and outputs
Educational use — demonstrating the underlying concept
Onboarding a colleague who needs the same calculation/conversion
Verifying a number or output before passing it on

Frequently asked questions

How are the secrets generated?: Via the browser's crypto.getRandomValues() API, which uses the OS's cryptographically-secure random number generator (CSPRNG). Output is base64-encoded for ASCII safety. The result is suitable for production secrets — same quality as `openssl rand -base64 32` from your terminal.
What's the difference between .env and .env.example?: .env contains REAL values (secrets, production credentials) and should be gitignored. .env.example contains the SAME KEYS with placeholder values and IS committed to the repo. New developers clone the repo, see .env.example, copy it to .env, and fill in real values from your secret manager. The example documents what's needed without leaking secrets.
Should I quote values?: Generally no for simple values: `DB_HOST=localhost`. Quote when value contains spaces or special characters: `DB_PASSWORD="my secret with spaces"` or `MESSAGE='Hello, World!'`. Single quotes preserve literally; double quotes allow escape sequences. Be aware: different dotenv parsers handle quoting slightly differently — test your specific library.
What's the JWT_SECRET supposed to look like?: A long random string — at least 256 bits (32 bytes) for HMAC signing. The standard recommendation is 64 bytes (512 bits) for HS512 or RS-family. Format: typically base64-encoded. Example: `JWT_SECRET=7K8mQpV3rN9wXdJ4lH6tY2sBuFcPaEz5oI1vM9nT0qWxAk=`. Don't hand-write this; the generator produces cryptographically-secure values.
Can I use the same .env across dev / staging / prod?: No. Each environment should have its own .env (or equivalent secret config) with values appropriate to that environment. dev: usually local/test resources, dummy keys. staging: real-but-isolated resources. prod: real production secrets. Same KEY names, different VALUES. .env.example documents the keys.
What about Docker / Kubernetes?: Docker: pass with `docker run --env-file .env image` or in docker-compose.yml. Kubernetes: convert to a ConfigMap (for non-secret values) or Secret (for sensitive values) using `kubectl create secret generic myapp --from-env-file=.env`. Both will read the same .env format.

Learn more

Explore more developer utilities tools

100% in-browserNo downloadsNo sign-upMalware-freeHow we keep this safe →