Environment File Generator
Paste a .env file and get what you need from it: a .env.example with secrets removed for the repository, a cleaned and sorted .env, or the same variables as JSON, YAML, shell exports, docker run flags, a Kubernetes ConfigMap and Secret, or a GitHub Actions env block. On the way, the file is checked for duplicate keys, unquoted spaces, invalid names, debug mode in production, live keys and differences from your .env.example.
- Runs in your browser
- No sign-up
- Free to use
How to use Environment File Generator
- Paste your .env file.
- Optionally paste .env.example to compare.
- Choose the output format.
- Review the findings and copy the result.
Environment File Generator features
.env.example
Secrets blanked, safe values kept, groups preserved.
Checks
Duplicates, invalid names, unquoted spaces, debug and live keys.
Comparison
Keys missing from or undocumented in .env.example.
Conversions
JSON, YAML, export lines and docker -e flags.
Kubernetes
ConfigMap for settings, Secret template for secrets.
CI
GitHub Actions env with secrets.* references.
When to use Environment File Generator
- Creating or updating .env.example before committing.
- Finding why a variable has the wrong value (it is set twice).
- Moving configuration into Kubernetes or CI.
- Reviewing a production .env for risky settings.
Environment File Generator FAQ
Which values count as secrets?
Keys containing PASSWORD, SECRET, TOKEN, KEY, PRIVATE, CREDENTIAL, AUTH, SALT or connection strings such as DATABASE_URL. Their values are removed from .env.example and moved to Secrets or secret references.
Why is a duplicate key a problem?
Most loaders use the last value, so an earlier line silently stops working, which is a frequent source of confusing bugs.
Why quote values with spaces?
Without quotes, some loaders cut the value at the first space or treat # as a comment. Quoting makes it unambiguous.
Is it safe to paste my .env?
Processing happens in your browser and nothing is sent or stored. Still, avoid pasting production secrets you are not allowed to copy.
What does the Kubernetes output contain?
A ConfigMap with the non-secret values and a Secret with placeholders for the secret ones, so the real values are never written into a file.
Is the comparison case-sensitive?
Yes, like environment variables on Linux.
Working with .env files
Most applications read their configuration from environment variables, and in development those usually come from a .env file. The real file contains secrets and must not be committed, while a .env.example documents which variables exist. Keeping the two in sync by hand is tedious, and converting the file for Docker, Kubernetes or CI is repetitive.
The parser follows dotenv rules: comments and blank lines are ignored, export prefixes are removed, single- and double-quoted values are unquoted and multi-line double-quoted values are supported. Each variable keeps its line number, so findings point to the exact place.
The checks catch problems that cause real bugs and incidents: keys defined twice, names that are not valid environment variable names, values with spaces but no quotes, APP_DEBUG=true together with a production environment, and live payment keys. With .env.example pasted, keys missing on either side are listed.
The .env.example output keeps the structure of the file, grouped by prefix, keeps harmless values such as APP_ENV or ports as documentation and empties every secret. Other outputs convert the same variables to JSON or YAML for tools, shell export lines, docker run flags or an --env-file recommendation, a Kubernetes ConfigMap plus a Secret template, and a GitHub Actions env block that reads secrets from the repository’s secret store.
Secrets are identified by their names, so a variable such as STRIPE_SECRET or DB_PASSWORD never appears in a generated file with its value except in the cleaned .env itself.