Catch .env Mistakes Before They Reach Production
Paste a file or drop it below and get every duplicate key, broken quote, and missing value flagged in seconds. It runs entirely in your browser, so the file never leaves your machine.
- 100% client-side
- Catches duplicates & broken syntax
- Sortable results table
- Drag, drop, or paste
What is a .env file?
A .env file stores your app's configuration as plain key-value pairs: API keys, database URLs, feature flags, anything that changes between your laptop and production. Frameworks like Next.js, Vite, and Rails read it automatically at startup and load each line into process.env.
Keeping that configuration in its own file instead of hardcoded in your source means you can hand a teammate the codebase without handing them your database password, and swap an entire environment by swapping one file.
Why use this tool?
A missing equals sign or a duplicate DATABASE_URL doesn't throw an error. It quietly loads the wrong value, and you find out during a deploy, not before one. Scanning a file by eye rarely catches that.
This tool reads every line and tells you exactly which one is broken: which key repeats, which quote never closes, which value is empty when it shouldn't be. Fix it here, then paste the clean version into your project.
What Gets Checked
Six checks run against every line you paste.
Duplicate keys
The same key defined twice. Most parsers keep the last one and drop the first without a warning, so you get the wrong value silently.
Empty keys
A line where the key portion is blank or missing, usually from a stray equals sign or a bad copy-paste.
Keys with spaces
A key containing a space character, which most shells and parsers reject outright.
Unclosed quotes
A value that opens a quote and never closes it, which can swallow every line after it into a single value.
Missing equals sign
A line that isn't a comment or blank but has no =, so it never parses as a variable at all.
URLs without a protocol
A value that looks like a URL but is missing http://, postgres://, or similar, which breaks most client libraries.
Common .env File Mistakes
Six ways a working .env file quietly stops working.
1. Duplicate keys
Define the same key twice and most parsers use the last occurrence, but that behavior isn't standardized across tools. A second DATABASE_URL added lower in the file, maybe pasted in during a rushed merge, can silently point your app at the wrong database with no error to warn you.
2. Unclosed quotes
Values with spaces usually need quotes, and forgetting the closing one is an easy typo with an outsized effect: some parsers will keep reading past the line break and fold the next variable into the same value.
3. Spaces in key names
Environment variable keys shouldn't contain spaces. A few parsers tolerate it, but it breaks the moment the file crosses into a shell or a platform that doesn't, and it usually comes from a copy-paste that grabbed a label along with the value.
4. Missing equals sign
Every real line in a .env file, apart from comments and blank lines, needs an equals sign separating key from value. Drop it, whether from a rushed edit or a copied shell command, and the line is ignored or throws depending on the parser.
5. URLs without a protocol
Leave off the protocol on a URL value, http://, https://, postgres://, redis://, and libraries that expect a full URL fail silently or throw an error that doesn't point back to the actual cause.
6. Empty values vs missing keys
KEY= and a key that isn't in the file at all are two different things: one sets an empty string, the other leaves the variable undefined. Code that checks if (KEY) treats both as falsy, but code that checks for undefined specifically won't.
The .env Viewer above catches all six of these automatically, line by line, before you ship.
Security Best Practices
Keep your secrets out of places they shouldn't be
Never commit .env files to Git
Once a credential lands in your Git history, removing it is a rewrite-history operation, not a delete. Anyone who cloned the repo before you noticed already has it, and on a public repo that includes anyone who was watching.
Use .env.example for documentation
A .env.example file lists every variable a teammate needs, with placeholder values, and it's safe to commit because it holds no real secrets. Update it whenever you add a new variable, or it stops being useful within a week.
Rotate secrets on a schedule
Rotate API keys and database passwords on a schedule, not just after something goes wrong. If you suspect a credential leaked, rotate it the same day, don't wait to confirm the leak first.
- Automate rotation where the provider supports it
- Use a secret manager, HashiCorp Vault, AWS Secrets Manager, or your host's built-in environment variables, instead of a plain file in production
- Review who has access to production credentials every so often
- Give each team member the minimum access their role needs
Split configuration by environment
Most frameworks load a different file automatically depending on the environment they detect. Lean on that instead of branching your code on NODE_ENV checks scattered through the app.
Validate variables at startup
Check that every required variable exists and looks right before your app accepts its first request. A missing DATABASE_URL should crash your app on boot with a clear message, not three requests into production.
Frequently Asked Questions
Questions we actually get about .env files