.env File Validator

The Env Validator parses and validates .env files for syntax errors, missing variables, duplicate keys, security issues, and compliance with a .env.example template. Environment variables are the standard way to configure applications (12-factor app principle), and .env files are the common way to manage them during development. But errors in .env files cause runtime bugs, missing required variables cause silent failures, and committing secrets to version control is a recurring security incident.

Paste your .env file and optionally your .env.example template, and the tool validates both. Checks: syntax (correct KEY=VALUE format, quote handling, escaping), duplicate keys (shadowing bugs), missing required variables (based on template), unexpected variables (not in template), secret leak detection (common patterns for API keys, tokens, passwords), and documentation completeness (each variable should be in .env.example with a description). All processing runs client-side so actual .env content stays in your browser.

.env file format is a simple KEY=VALUE per line:

DATABASE_URL=postgres://user:pass@localhost:5432/db
API_KEY=secret123
DEBUG=true

Rules:
- One variable per line
- KEY before =, VALUE after
- KEY typically uppercase with underscores (convention)
- No spaces around = (some parsers allow, some don\u2019t)
- Comments start with # (whole line or end of line depending on parser)
- Blank lines allowed
- Quoted values: \"value with spaces\" or 'value with spaces'
- Escaped characters in values: \\n, \\t, \\\"
- Multi-line values: \"line1\\nline2\" or in some parsers with triple quotes

Parser differences exist between implementations (Python dotenv, Node dotenv, Laravel .env, Ruby dotenv). This tool targets the most common subset.

Validation checks:

1. Syntax:
- Each non-blank, non-comment line matches KEY=VALUE format
- Quotes are balanced
- Escape sequences are valid

2. Duplicates:
- Same KEY defined multiple times (last typically wins but behavior varies)

3. Naming conventions:
- UPPER_CASE_WITH_UNDERSCORES
- Starts with letter or underscore
- Alphanumeric and underscores only

4. Template compliance (with .env.example):
- Every key in template exists in .env
- No keys in .env that aren\u2019t in template (unexpected extras)
- Flag missing with appropriate warning level (required vs optional)

5. Security:
- Detect placeholder values in production .env (e.g., changeme, secret, xxx)
- Detect common API key patterns committed to version control
- Flag potentially unsafe values (very short, dictionary words)

6. Documentation:
- Each variable should have a comment above it in .env.example
- Missing documentation flagged as warning

Parsing edge cases:
- Value contains #: PASSWORD=secret#1. Some parsers stop at #; others preserve. Quote the value to be safe: PASSWORD=\"secret#1\"
- Value contains =: DATABASE=postgres://a=b. First = is the separator; rest is value
- Empty value: KEY= vs KEY=\"\" (both valid, meaning varies)
- Missing value: KEY (without =, some parsers accept as KEY=)

Output:
- List of all variables with values masked (first 3 chars shown for verification)
- Categorized issues: errors (must fix), warnings (should fix), info
- Recommendations for each issue

Compared to running your app to find missing variables, this tool catches problems instantly without startup time. Runtime errors are often cryptic; this validation is explicit.

Compared to writing custom validation scripts, this tool covers common checks out of the box. For sophisticated validation (type checking, regex patterns per variable), custom scripts are more flexible.

Compared to secret scanning tools (TruffleHog, GitLeaks), this tool is for format validation; those scan for leaked secrets in git history. They complement each other.