Why validate against .env.example at all?
Most projects commit a .env.example (or .env.sample) file that lists every environment variable the application expects, usually with empty or placeholder values. The real .env files stay out of version control because they hold secrets and machine-specific values.
The problem is drift. A teammate adds a new variable to .env.example but your local .env never gets it. A key is renamed in code but the old name lingers in production. A value gets pasted twice. None of this is visible until the app crashes on boot or, worse, silently reads an empty string. Validating one file against the other turns those invisible mismatches into a list you can act on.
Step 1: Treat .env.example as the source of truth
Decide which file is the template. In almost every project that is .env.example, because it is reviewed, committed, and shared across the team. Every required key should appear there, even if its value is blank.
A useful rule: a template key with no value is required, and a template key with a default value is optional. That distinction lets a validator tell the difference between "you forgot to set DATABASE_URL" and "you left LOG_LEVEL at its default", instead of flagging everything.
Step 2: Compare your real .env against it
Load the template and the environment file side by side and look for four categories of issue. Missing keys: required template keys that are absent from the environment file. Extra (undocumented) keys: keys present in the environment file but not in the template, which are often typos or leftover variables. Duplicates: the same key assigned more than once, where the last assignment silently wins. Malformed lines: entries that are not valid KEY=value pairs.
The browser-based .env file validator on this site does exactly this. Paste or drop your .env.example and up to three environment files, and it highlights each category and links every key to the exact file and line it appears on, with no upload to a server.
Step 3: Fix and re-check
Add the missing keys, remove or rename the undocumented ones, collapse duplicates to a single assignment, and repair malformed lines. Then run the comparison again until the report is clean.
For teams, the same check is worth running in CI before a deploy, so a missing or malformed variable fails the pipeline instead of the production server. Validating locally first simply makes that gate faster to pass.