.env Helper — Generate .env.example, Scan for Secrets, Diff Environments
Generate .env.example from a .env file, scan for accidentally committed secrets, and diff staging vs production. All in your browser. No uploads.
.env Helper
Generate .env.example, scan for known secret formats, or diff two .env files — 100% local.
.env files are the simplest way to configure a 12-factor application: one KEY=value pair per line, comments start with #, blank lines are ignored, and the application reads the file at startup. The format is so simple that it has become the de facto standard for development configuration across every language and framework — Node.js, Python, Go, Ruby, PHP, Java all have libraries that parse .env files. The complexity comes from the lifecycle: there is a .env file for local development, a .env.staging for the staging server, a .env.production for production, and a .env.example that gets committed to the repo so new developers know which keys to set. Keeping all of those in sync is the chore the tool here addresses.
The non-obvious thing about .env management is the security boundary. The .env file with real values never goes into version control — the .gitignore has .env on the first line. The .env.example file is the safe-to-commit version: it has the same keys, with placeholder values, and serves as documentation. The mistake every team makes at least once is committing a .env with a real API key, a database password, or an OAuth client secret. The secret-scan mode here is the safety net for that mistake: it pattern-matches high-entropy strings and known key prefixes (AWS, Stripe, GitHub, Slack, Google) and flags anything that looks like a real credential before it lands in a public repo.
For a final hand-off: if the goal is setting up a new project, run Generate Example on your .env and commit the result — new developers copy it to .env and fill in the values. If the goal is a security audit, run Scan Secrets on every .env file in the repo and address the high-severity findings. If the goal is comparing environments, run Diff with your staging and production .env files and verify that staging has everything production has, with no production-only keys leaking into staging by accident. The three modes cover the three most common .env management tasks; for ongoing maintenance, set up a pre-commit hook with a secret scanner (gitleaks, trufflehog) that catches the problem before the commit lands.
How to use
Paste your .env file
Drop the .env contents into the input area, or load a .env file. The parser handles standard KEY=value lines, comments starting with #, quoted values, and multiline values wrapped in quotes.
Pick a tool mode
Switch between Generate Example (strips values, keeps keys and comments), Scan Secrets (flags AWS keys, Stripe keys, GitHub tokens, and other high-entropy strings), and Diff Environments (compares two .env files side by side).
Copy or download the result
Copy the generated .env.example, the secret scan report, or the diff to your clipboard. The output is plain text — paste it into your editor or your commit message.
Frequently asked
What secrets does the scanner detect?
The scanner uses pattern matching plus entropy analysis. It catches AWS access keys (AKIA...), Stripe secret keys (sk_live_...), GitHub tokens (ghp_..., gho_...), Slack tokens (xoxb-...), Google API keys (AIza...), and any 40+ character base64/hex string that looks like a key.
How does Generate Example work?
Generate Example takes a .env file and produces a .env.example by replacing every value with a placeholder (empty string, 'changeme', or 'your-key-here' depending on the value's purpose). Keys and comments are preserved exactly. The result is safe to commit to a public repo.
What does the environment diff show?
The diff has four sections: keys in both files (matching or different values), keys only in the first file, keys only in the second file, and value mismatches. Useful for verifying that staging has all the keys production has, and that no stale keys linger in either environment.
Will the scanner flag my test API keys?
The scanner flags any string matching the high-entropy patterns, including test keys. If the test keys are intentionally safe to commit (Stripe's `sk_test_...`, GitHub's `gho_test_...`), the scanner labels them as low-severity. Production keys are flagged as high-severity.
Does the tool store my .env contents?
No — the tool runs entirely in your browser. The .env content is parsed in memory and never sent to a server. The browser tab's memory holds the content until you close the tab or click Reset, at which point it is garbage-collected.
Limitations
- Pattern-based detectionThe secret scanner uses regex patterns plus entropy heuristics. False positives are possible (a long random string that is not a secret) and false negatives are possible (a short secret that does not match a known pattern). Use the scanner as a safety net, not a primary defense.
- No automatic redactionThe scanner flags secrets but does not rewrite the .env file. To produce a safe-to-commit version, manually replace the flagged values or use Generate Example, which strips all values regardless of whether they look like secrets.
- Diff is text-basedThe environment diff compares key-value pairs as text. Reordered keys are not flagged as differences (the diff sorts keys before comparison), but reordered values in a list-style variable are flagged because the order matters in some environments.
Platform notes
- macOS
- macOS Terminal: `diff <(grep -v '^#' .env.staging | sort) <(grep -v '^#' .env.prod | sort)` is the CLI equivalent of the diff tool. The browser tool is the right pick for content pasted from a chat, an email, or a docs page where retyping is impractical.
- Windows
- PowerShell: `Compare-Object (Get-Content .env.staging) (Get-Content .env.prod)` is the CLI equivalent. The browser tool is the right pick for cross-platform consistency — the same input produces the same output on every platform.
- Linux
- GNU coreutils: `comm -23 <(sort .env.staging) <(sort .env.prod)` shows keys only in staging. The browser tool combines all three modes (generate, scan, diff) in one interface — useful for one-off checks where scripting is not warranted.
- CLI
- The same secret-detection patterns are available in the `gitleaks` and `trufflehog` CLI tools. The browser tool is the right pick for ad-hoc checks on a single .env file; for a pre-commit hook or a CI pipeline, the dedicated CLI tools are the right pick.
- Web
- Runs entirely client-side. Works offline once the page has loaded. The .env content is parsed in memory and never sent to a server — safe to use with production credentials, though the standard advice (do not paste secrets into browsers) still applies.