ENV File Validator

Overview

Checks a .env file for syntax errors, duplicate keys, and empty values, then compares its keys against a .env.example to find what is missing locally and what exists only locally. Both panels parse live, and a verdict line summarizes the total issue count. Everything is text processing in the browser; your secrets are never uploaded.

How It Works

Paste your local .env into the upper panel and your .env.example into the lower one. The tool reports, line by line, any line that is not blank, a comment, or a KEY=value assignment (an optional export prefix, inline comments and quoted values that span several lines are understood, and an unterminated quote is reported); it lists duplicate keys that appear more than once; it flags keys whose value is empty; it lists example keys absent from your local file; and it lists local-only keys as a friendly FYI. The verdict card shows a green pass when there are no errors, duplicates, or missing keys; syntax errors in the example file count too, and empty values are listed but do not fail the check.

Step-by-Step Usage Guide

1. Paste your local .env contents into the first panel.
2. Paste the project's .env.example into the second panel.
3. Fix any syntax errors first; they are reported with line numbers.
4. Resolve duplicates and empty values, then add the missing keys the example expects.

Technical Specifications & Standards

The parser implements the common dotenv dialect with specific boundaries worth knowing. A valid line matches an optional export prefix, a key of letters, digits, underscores, dots and hyphens starting with a letter or underscore, an equals sign, and a value, which may be single-, double- or backtick-quoted and may continue over several lines until the closing quote, with a trailing comment allowed after it; anything else, such as a line with no equals sign or a key starting with a digit, is a syntax error with its line number. Comment lines starting with # and blank lines are skipped. Whitespace around the key and before the value is tolerated, and values containing equals signs are preserved whole because the value is everything after the first =. Empty-value detection finds keys assigned nothing, which usually means an unset variable that will surface as undefined in your app at runtime. Duplicate detection matters because dotenv loaders can disagree about which duplicate wins (Node's dotenv keeps the last one), so a duplicated key with a changed value can silently keep the wrong value, a classic source of works-on-my-machine bugs. The example comparison is directional on purpose: missing keys fail the check because the app will crash or misbehave without them, while extra local-only keys are informational, since throwaway or machine-specific variables are legitimate.

Targeted Use Cases

• Pre-flight checking a .env before deploying, when a missing key means a 500 error at boot.
• Onboarding a teammate by verifying their local file has every key the example defines.
• Hunting down a config value that never changes despite editing it, usually a duplicate key.
• Auditing for accidentally empty secrets such as blank API keys or empty database URLs.

Notes & Gotchas

• Run the check before every deploy; missing keys fail at startup, which is the worst time to learn about them.
• Delete duplicate lines rather than editing one occurrence; loaders can disagree about which duplicate wins.
• Investigate empty values even when the key exists, since an empty secret often authenticates as nothing.
• Keep .env.example in the repo and .env out of it; the comparison only works when the example is maintained.

Frequently Asked Questions