Why it matters
Environment files hold the settings and secrets an app needs, and they go wrong quietly: a duplicate key where the second one wins, a missing quote that swallows the next line, or a key in .env.example that nobody set in production.
This checker parses the file the way dotenv does, explains every problem and writes a .env.example with the values removed, so you can commit the shape of your config without the secrets. Values stay on the page and are masked on screen unless you choose to show them.
How it works
- InputA .env file and its example
- In your browserParsed like dotenv, values compared
- OutputMissing keys, risky secrets and a safe example
Where it fits in a designer's workflow
- Plan
- Design
- Build
- Test
- Launch
By the numbers
Show the numbers as a table
| Check | Count |
|---|---|
| Missing from .env | 1 |
| Empty but required | 1 |
| Not in the example | 2 |
| Look like real secrets | 1 |
| Syntax issues | 4 |
How to use it
- Paste your .env file (values are masked).
- Optionally paste .env.example to compare.
- Fix the problems listed.
- Download the generated .env.example to commit.
FAQ
Is my .env uploaded?
No. It's parsed in your browser and values are masked on screen. Still, never paste production secrets into sites you don't trust.
Which value wins if a key appears twice?
With dotenv, the last one in the file. Other loaders may take the first, which is why duplicates are flagged.
How does it spot secrets?
From key names (SECRET, TOKEN, PASSWORD, KEY), known prefixes such as sk_live_ and ghp_, and long random-looking values.
Should .env be committed?
No. Add it to .gitignore and commit .env.example instead.
