Env File Validator
Lint your .env file for syntax errors, duplicate keys, quoting mistakes and risky patterns. Paste the content, click Validate, and fix every flagged line. Everything runs inside your browser — your secrets are never uploaded or stored.
Validation summary
Findings
| Line | Severity | Message |
|---|
Sanitized output
A copy-safe version where values of keys containing SECRET, PASSWORD, KEY or TOKEN are replaced with ***. Useful when sharing your .env for debugging.
How to use
- Paste your .env file content into the box above.
- Click Validate. Each line is checked for format, duplicates, quoting and risky patterns.
- Review the findings table — red Error badges break parsing, amber Warning badges deserve a look.
- Use Copy sanitized output to get a version with secrets masked as
***.
What is checked
- Line format: every non-comment line must be
KEY=valuewith an=sign. - Key format: keys should match
^[A-Z_][A-Z0-9_]*$— lowercase keys get a warning. - Duplicate keys — reported as errors with both line numbers.
- Empty values, unquoted values containing spaces, and unquoted
$values that shells may expand.
Frequently asked questions
Why does the validator warn about lowercase keys?
By convention .env keys are UPPER_SNAKE_CASE like APP_NAME. Lowercase keys such as app_name still work in most parsers, but frameworks may treat them differently, so the validator flags them as a warning to review.
When should I quote a value in a .env file?
Quote values that contain spaces or special characters, for example GREETING="hello world". Unquoted values with spaces can be split or truncated by some parsers.
What happens if I define the same key twice?
Most parsers use the first or the last definition and ignore the other, which causes confusing bugs. The validator reports every duplicate key as an error so you can remove the extra line.
Is my .env content uploaded anywhere?
No. The validation runs entirely in your browser with JavaScript. Your .env content never leaves your device.