.env File Validator
Check environment-variable files for malformed lines, invalid keys, duplicate keys, missing values and the formatting mistakes that break deployments — without uploading your secrets.
Paste the contents of a .env file (or upload the file itself) and the validator parses it the way
the major loaders do — python-dotenv, Node's dotenv, docker-compose and a plain shell
set -a; . .env — then flags every line where those loaders disagree or where a classic
mistake hides: unquoted $ that a shell will expand away, inline comments that become part of a
password, duplicate keys where the last one silently wins, Windows line endings, and more.
You get a line-by-line report, an interpolation reference map, and a cleaned-up file you can copy or download.
Paste or upload your .env file
Validation runs live as you type. File uploads are read locally in your browser — the file never leaves the page.
Line-by-line report
| Line | Key | Value | Severity | Message |
|---|
No issues at this severity — the file is clean here.
Interpolation references
Values that reference other keys with $KEY or ${KEY}. Only some loaders
(docker-compose, a few dotenv variants) actually expand these — python-dotenv and shell keep
them literal.
Export
The cleaned file normalises line endings to LF, drops the BOM, ensures a trailing newline and double-quotes any value containing characters a loader might mangle — comments are preserved. It contains only the lines that parsed successfully.
The .env mistakes that actually bite
A .env file is read by at least two different kinds of software — a dotenv-style parser in your application, and often a shell that sources it during deployment. They disagree on quotes, escapes, comments and interpolation, and most mistakes fail at 3am, not in review. These are the ones that show up most often:
- Unquoted
$and backticks.API_URL=https://api.example.com/v1/$TOKENis fine to most dotenv parsers, but the moment a deploy script runsset -a; . .env, the shell expands$TOKEN— usually to an empty string — and your URL is nowhttps://api.example.com/v1/. Double-quote any value containing$. - Inline comments in unquoted values.
PASSWORD=abc123 # production— many dotenv parsers keep# productionas part of the password, so login fails with a credential that looks correct. Quote the value or move the comment to its own line. - Duplicate keys. If
DB_HOSTappears twice, most loaders silently keep the last value. The first one is dead config that misleads everyone who reads the file top-down. - Windows line endings (CRLF). Editing on Windows and deploying on Linux adds a hidden
\rto the end of every value. Some parsers strip it, some don't — a trailing carriage return in a JWT secret is invisible and fatal. Save as LF. - UTF-8 BOM. A few editors (some Windows ones, notably) prepend an invisible BOM
character. Most loaders cope; a few fold it into your first key name, so
SECRET_KEYquietly becomes\uFEFFSECRET_KEY. - Whitespace before
=.DB_PORT = 5432looks harmless, but a shell will try to runDB_PORTas a command and most dotenv parsers reject the line outright. - Empty values.
SMTP_PASSWORD=is either an empty string or undefined, depending on the loader — and the error message you get months later will not mention which one it was. - Committing the file itself. The rule that keeps .env files safe:
.envgoes in.gitignore, and a.env.examplewith the same keys but dummy values is what gets committed. This validator is useful for checking the example file too — it's the schema your teammates copy from.
Suggested
