Why .env files fail quietly
Most dotenv loaders do not throw on a bad line. They skip it, or worse, read the rest of the file as part of one value. A missing closing quote on STRIPE_KEY can turn the next five variables into a single multi-line string, and the app only fails later with “DATABASE_URL is not defined”. Validating the file first turns that hunt into a one-line fix.
The validator applies the common dotenv rules used by Node’s dotenv, Docker Compose, Python’s python-dotenv and similar loaders:
- each line is
NAME=value, optionally prefixed withexport; - names start with a letter or underscore and contain letters, digits, underscores, dots or dashes, so
2FA_SECRETis rejected; - a name cannot contain spaces, which is why
API URL=...is reported as a missing=; - double-quoted values may span lines but must be closed; single-quoted values are literal and must be closed too;
- after a closing quote, only a
#comment may follow.
Errors, warnings and positions
Errors stop the check and point at the exact spot: Unterminated double-quoted value for STRIPE_KEY starting at line 1 tells you which variable and where its quote opened, not where the file happened to end. The input line is highlighted, and the output pane keeps the last clean version faded out so you can still read the other variables.
Duplicates are warnings: Duplicate variable 'NODE_ENV' (first defined on line 1). Within one file, Node’s dotenv and python-dotenv both keep the last value, yet by default neither replaces a variable that is already set in the real environment, so which value your process sees is easy to misjudge. A file saved on Windows is handled too: CRLF line endings are normalised and a leading byte-order mark is dropped with a note, so the first variable name does not silently start with an invisible character. Either way, a duplicate in a committed .env.example or a deployment file is almost always a mistake.
What it cannot verify
Values are not checked for meaning. An invalid URL, a port of 99999, a malformed JSON value or a key from the wrong environment all pass. Variable expansion such as ${HOME}/data is kept as text and not resolved, since loaders differ on whether they support it. Nor does the validator compare your file with .env.example to find missing variables; diff the two files for that.
This is the one file type where privacy is the whole point: it usually holds database passwords, API keys and signing secrets. The validator reads it inside your browser and never uploads it. Still, do not paste a production .env into a share link, and rotate anything that has been exposed.
Examples
Unclosed quote swallows the next variable
Invalid: the quote after STRIPE_KEY= is never closed, so a loader would read the following lines as part of the key.
STRIPE_KEY="sk_test_4eC39HqLyjWDarjtT1zdp7dc
DATABASE_URL=postgres://shop:secret@localhost:5432/shop
NODE_ENV=production
Line 1, column 12: Unterminated double-quoted value for STRIPE_KEY starting at line 1Variable name starting with a digit
Invalid: 2FA_ISSUER begins with a digit, which shells and most loaders do not allow.
APP_NAME=PasteKit
2FA_ISSUER=PasteKit
SESSION_TTL=3600
Line 2, column 1: Invalid variable name '2FA_ISSUER' on line 2Doubled single quote in a literal value
Invalid: single-quoted values cannot escape a quote, so the text after the second ’ is reported as unexpected.
export AWS_REGION=ap-southeast-1
WELCOME_TEXT='it''s live'
Line 2, column 18: Unexpected text after the closing quote of WELCOME_TEXT on line 2Valid file with a duplicate
Passes with a warning: NODE_ENV is defined twice, and the warning gives the line of the first definition.
NODE_ENV=production
PORT=3000
LOG_LEVEL=info
NODE_ENV=development
NODE_ENV=production
PORT=3000
LOG_LEVEL=info
NODE_ENV=development
Common errors and how to fix them
| Error | Cause | Fix |
|---|---|---|
Unterminated double-quoted value for STRIPE_KEY starting at line 1Explained | A double-quoted value has no closing quote anywhere below it. | Add the closing " at the end of the value. |
Invalid variable name '2FA_SECRET' on line 1 | The name starts with a digit or contains characters such as spaces or slashes. | Rename it to start with a letter or underscore, for example TWO_FA_SECRET. |
Missing '=' after API on line 1 | The name contains a space, or the line has no = at all. | Use underscores in names (API_URL=…) and make sure every line has an =. |
Unexpected text after the closing quote of MESSAGE on line 2 | Something other than a # comment follows a quoted value, often an attempt to escape a quote by doubling it. | Switch to double quotes and escape inside them, or start the trailing text with #. |
Frequently asked questions
Which dotenv syntax does the validator follow?
The common subset used by dotenv for Node, python-dotenv, Docker Compose env_file and most frameworks: NAME=value lines, optional export, # comments, and single or double quotes.
Are multi-line values allowed?
Yes, inside double quotes, which is how private keys are usually stored. The quote must be closed after the last line.
Are spaces around = an error?
No, the validator accepts them. Some loaders and shells do not, so the .env formatter writes NAME=value without spaces.
Is it safe to paste a .env with real secrets?
The file is processed only in your browser and is never uploaded. Avoid putting secrets in share links, and treat any secret that has left your machine as compromised.