.env Validator Online — Catch Missing Keys Free
Check a .env file for the failures that break deployments at 2am — missing required keys, silent duplicate overrides, malformed lines, and suspicious values — against your .env.example or a pasted key list.
- Paste your .env.example (or just a list of key names) as the reference to catch missing keys.
- Errors block deployment; warnings are heuristic (short secrets, non-numeric ports, missing URL schemes).
- Run it before every deploy — it takes two seconds and catches the wrong-environment mistake.
Your .env file is the most sensitive text in your repo — database passwords and signing keys included. Parsing, cleaning, and conversion all run in your browser. Nothing is uploaded, stored, or logged.
What gets flagged
Errors are structural: lines without KEY=value syntax, keys defined twice (most loaders silently keep the last), and keys present in your reference but missing here — the classic deploy-to-staging-with-production-env failure.
Warnings are judgment calls the parser can make mechanically: a PORT value that is not numeric, a *_URL without a scheme, a *_SECRET shorter than 16 characters, unquoted values containing spaces. Each warning names the key so you can decide.
A pre-deploy ritual
Keep a committed .env.example as the contract. Before deploying, paste the target environment's real .env and the example, and read the missing-keys section — it is a checklist of exactly what will be undefined at runtime. process.env.MISSING_KEY does not throw in Node; it silently returns undefined and the failure surfaces later, in production, as something else.
That is the whole argument for validating: env validation failures are quiet until they are expensive.
Private by construction
Validation runs entirely in your browser. The real values — secrets included — are never uploaded, stored, or logged.
The .env rules that trip people
Environment files look trivially simple and are parsed surprisingly loosely, so a value can be silently truncated before it ever reaches your code. These are the lines that cause real incidents:
- An unquoted # starts a comment. PASSWORD=abc#123 loads as abc unless the value is quoted — the most common silent truncation.
- An export prefix is accepted by some loaders and not others, so it works locally and fails in a container. Omit it.
- Spaces around the = are usually trimmed, but a value with meaningful leading or trailing spaces needs quotes to keep them.
- Double quotes interpret escape sequences and variable expansion; single quotes are literal. The same line can mean different things to different loaders.
- A multi-line value only works when quoted, and not every loader supports it.
What it cannot check
The validator checks structure and shape, not truth. It can tell you a key is missing, duplicated, or malformed, and that a value looks wrong for its name. It cannot tell you the value is the right one — a valid-looking production password in a staging file passes every mechanical check.
The reference list is only as good as its upkeep. If .env.example has drifted from what the code actually reads — a key renamed in code but not in the example — the contract is wrong, and this tool trusts the contract. Keep the example reviewed alongside the code that consumes it.
Frequently asked questions
What counts as the reference format?
Either an .env.example-style document (any KEY=value lines, values usually empty) or a bare list of key names separated by commas, spaces, or newlines. The tool detects which one you pasted.
Why are duplicates an error when loaders allow them?
Because loaders resolve them silently — usually last-wins — and nobody reading the file can tell which line is live. One of the two definitions is a bug; the tool makes you look at it.
Are my env values uploaded during validation?
No. Parsing and checking happen locally in your browser. This page is safe to use with production secrets.
Does this check whether my values are correct?
No. It checks structure and shape — missing keys, duplicates, malformed lines, and values that look wrong for their name. A valid-looking value from the wrong environment passes; the tool cannot know your production secret.
Why does my value get cut off at a #?
An unquoted # starts a comment, so everything after it is ignored. Quote the value (PASSWORD='abc#123') if the # is part of it.