Env File Tool
Parse, convert, and generate .env.example files from your .env — catch duplicate keys before they cause bugs
About this tool
The Env File Tool parses a .env file, flags duplicate keys before they cause a confusing bug, converts it to JSON, and generates a safe-to-commit .env.example with every value stripped but every key preserved. A missing or outdated .env.example is one of the most common onboarding friction points on a team — a new developer clones the repo, runs the app, and it fails with no clear indication of which environment variables were actually required. This tool keeps that file trivially easy to regenerate from the real .env. Two deployment-target exports round out the conversions: docker run -e flags (ready to paste straight into a docker run command) and a Kubernetes ConfigMap + Secret pair, with keys automatically split between the two based on common naming patterns (anything matching PASSWORD, TOKEN, SECRET, KEY, and similar goes into the Secret; everything else goes into the ConfigMap).
When to use it
- →Generating an up-to-date .env.example whenever new environment variables are added, so onboarding a new teammate doesn't require guessing
- →Catching duplicate keys in a .env file — the last one silently wins, which is a common source of 'why isn't my config taking effect' bugs
- →Converting a .env file to JSON for tooling that expects configuration as JSON rather than KEY=value pairs
- →Auditing exactly which keys a .env file defines before sharing a sanitized version with a teammate or in documentation
- →Turning a local .env into docker run -e flags or a Kubernetes ConfigMap/Secret pair without hand-copying every variable
Tips
- ◆Regenerate .env.example every time you add a new environment variable — a stale one is worse than none, since it silently omits a variable someone actually needs to set.
- ◆The duplicate-key check exists because .env parsers universally let the last occurrence of a key win with no warning — this is one of the most common invisible config bugs.
- ◆Quoted values ('...' or "...") have their quotes stripped automatically when converting to JSON, matching how most .env parser libraries (dotenv, python-dotenv) behave.
- ◆Never paste a production .env with real secrets into a tool you haven't verified is client-side only — this one is, but make that check a habit.
- ◆Always review the Kubernetes tab's ConfigMap/Secret split before applying it — the PASSWORD/TOKEN/SECRET-style key matching is a helpful default, not a substitute for checking which values are actually sensitive.
Frequently asked questions
Is it safe to paste a .env file with real secrets into this tool?
Yes — parsing, duplicate detection, and both conversions run entirely in JavaScript in your browser. Nothing is uploaded to a server. That said, treat any tool handling real secrets with healthy caution generally, and prefer generating the .env.example from a copy with placeholder values if you're at all unsure.
Why does a duplicate key in .env not cause an error when I run my app?
Virtually every .env parser (dotenv for Node, python-dotenv for Python, and others) silently lets the last occurrence of a duplicate key win, with no warning printed. This means a duplicate can sit in a .env file for months, quietly overriding an earlier value, until someone spends an hour debugging why a config change 'isn't taking effect' — when in fact a later duplicate line was overriding it the whole time.
What exactly goes into the generated .env.example?
Every key found in your .env file, each set to an empty value (KEY=), with no actual secrets included. This preserves the complete list of what needs to be configured — which is the entire point of an example file — without exposing any real credentials, API keys, or connection strings.
Does this tool support export KEY=value syntax?
Yes — the export prefix (used so a .env file can also be sourced directly in a shell with source .env) is stripped automatically during parsing, so both export DATABASE_URL=... and DATABASE_URL=... parse identically.
How does the tool decide which keys go into the Kubernetes Secret vs. the ConfigMap?
It checks each key name against a pattern matching common sensitive-value naming conventions — anything containing SECRET, PASSWORD, TOKEN, KEY, PRIVATE, CREDENTIAL, or AUTH goes into the Secret; everything else goes into the ConfigMap. This is a naming-based heuristic, not a security scan — always review the split yourself before applying it, since a value can be sensitive without its key matching any of those patterns.