.env Syntax Validator

A broken .env is the quietest kind of bug. It loads fine, the process starts, and only later do you discover DEBUG=true was actually DEBUG = true (with spaces), or a duplicate DATABASE_URL silently discarded the first value, or a key with an em-dash that one parser accepts and the next rejects.

The .env Syntax Validator scans your file and reports every structural problem with the exact line number: lines missing an equals sign, invalid key names, unbalanced quotes, duplicates, spaces around =, empty values, and line-ending inconsistencies. Errors break parsing; warnings flag things that many parsers tolerate but some tooling will not.

The verdict is instant and the report never shows value contents — only keys and line numbers — so you can validate files that contain secrets without leaking them. Run it in CI, run it before every deploy, or run it when you inherit an unknown .env.

• Line-level diagnostics: every issue tagged with its line number.
• Error vs warning: clear severity so you know what to fix.
• Duplicate detection: all lines of a repeated key reported.
• Quote balance: unclosed or mismatched quotes flagged.
• Spacing checks: spaces around =, trailing whitespace, tabs.
• Secret-safe: values are never echoed, only keys.
• Pass/fail verdict: overall status with counts per category.
• Private: all checking happens in your browser.

1. Paste your .env content into the input box, or load the sample which demonstrates several issues.
2. Click Validate. The verdict and the full diagnostic list appear.
3. Review each line number against your file and fix the reported issues.
4. Re-run until the verdict is clean.

Example 1 — Pre-deploy check. A CI pipeline pastes the generated .env into the validator and blocks the deploy on any error, catching a stray space around DEBUG before it reaches production.

Example 2 — Inherited config audit. A new maintainer validates an unknown .env and immediately sees three duplicate keys and a malformed line that the old parser tolerated.

Example 3 — Framework migration. A team moving from one dotenv parser to another runs both files through the validator to find syntax the new parser rejects.

Example 4 — Secret hygiene. An engineer runs the validator on a file full of credentials; the report shows only keys and lines, so nothing sensitive is exposed.

Example 5 — Template QA. A platform team validates every committed .env.example before shipping it, so contributors never inherit a broken starting point.

• Catches silent bugs: spacing and duplicate issues found early.
• Line-exact: every diagnostic points to a line to fix.
• Clear severity: errors versus warnings at a glance.
• Secret-safe: values never appear in the report.
• Deterministic: same file, same report, easy to test.
• Private & free: browser-only, no account.