.env File Validator

Node.js developers debugging a dotenv load failure, DevOps engineers preparing a Docker Compose environment, and security reviewers scanning for committed secrets all parse .env files differently and hit different bugs. This validator checks syntax, duplicate keys, unquoted hashes, export prefixes, BOM bytes, and secret-shaped values without uploading the file. Paste your config, review the findings, and fix issues before they become a 2 a.m. production incident.

.env Input

Findings

How the Validator Parses Environment Files

The validator splits the input on line breaks and processes each line independently. Comments and blank lines are skipped. For data lines, the first equals sign separates the key from the value; the key is trimmed and validated against the allowed identifier pattern, and the value is inspected for quoting, hash characters, and secret-shaped content. Duplicate keys are tracked in a map so later occurrences can reference the line of the first definition.

Secret detection runs a set of regular expressions against the cleaned value: AWS Access Key IDs, GitHub tokens, Slack tokens, Google API keys, OpenAI-style keys, and PEM headers. Keys whose names match password, secret, token, api_key, private_key, or access_key receive an informational reminder regardless of the value, so a placeholder is still flagged for a human review.

Errors vs. warnings vs. info

Errors break parsing: missing equals, empty keys, invalid key characters, and unterminated quotes. Warnings indicate likely bugs: duplicate keys, unquoted hashes, export prefixes, empty values, and secret-shaped content. Info items are portability notes: unquoted spaces, unquoted interpolation characters, CRLF line endings, and credential-suggestive key names.

Secret detection without false alarms

Secret patterns require both a name match and a value that fits the known format. A key called API_TOKEN with value changeme triggers only the informational key-name reminder, not the full secret warning. A key called AWS_ACCESS_KEY with a real AKIA... value triggers the explicit AWS warning.

Before and after: fixing a broken .env

Before (2 errors, 3 warnings)

DATABASE_URL=postgres://localhost/mydb
JUST_A_LINE
DEBUG=true
DEBUG=false
API_ENDPOINT = https://api.example.com/v1
FRONTEND_URL=https://app.example.com#dashboard
export SECRET_TOKEN=abc123

After (0 errors, 0 warnings)

DATABASE_URL=postgres://localhost/mydb
DEBUG=true
API_ENDPOINT=https://api.example.com/v1
FRONTEND_URL="https://app.example.com#dashboard"
SECRET_TOKEN=abc123

Use Cases

Developer	Production	Workflow
Debug why a dotenv variable loads as undefined	Scan a committed .env for real secrets before a public push	Validate a Docker Compose env_file before deploy
Catch duplicate keys that silently override values	Standardize quoting conventions across a team	Review a contributor's .env.example in a PR
Find BOM bytes that break the first variable on Windows	Audit env files for export prefixes before CI injection	Onboard a new engineer to the project's env conventions

Common Mistakes and Troubleshooting

The most common issue is an unquoted value containing a hash, which gets truncated at the comment marker. The second is a duplicate key where the later value silently wins, so the first value appears to be ignored. The third is the export prefix, which works in bash but leaves the literal export in the key name on Docker Compose and many dotenv parsers.

If the validator reports no errors but a variable still loads as undefined, check that your application reads the same key name you defined. Environment variables are case-sensitive on Linux. Also confirm the file is actually loaded: many frameworks look for .env in the working directory, not next to the entry script.

Best Practices for .env Files

Always quote values that contain spaces, hashes, or dollar signs. Never use the export prefix. Keep one definition per key and remove stale entries when rotating credentials. Add .env to .gitignore and commit a .env.example with placeholder values instead. Use LF line endings for cross-platform compatibility, and avoid BOM bytes by saving files as UTF-8 without signature.

Pair this validator with a gitignore generator to confirm .env is excluded, a Docker Compose generator for multi-service env files, and a password strength checker for credential quality. For CI, run the validator on every .env.example to catch drift before it reaches production.

.env File Validator FAQ

What does this .env validator check?

The validator checks for missing equals signs, empty keys, keys with spaces or starting with numbers, duplicate keys, unquoted values containing hash characters, export prefixes that some parsers do not strip, unterminated quotes, empty values, BOM at the start of the file, CRLF line endings, and values that look like AWS keys, GitHub tokens, Slack tokens, Google API keys, or PEM private key material. Each finding includes the line number and a plain-language explanation.

Why does the validator flag unquoted values with hash characters?

Most .env parsers treat a hash as the start of a comment. A value like FRONTEND_URL=https://app.example.com#dashboard is truncated at the hash, so the fragment is lost. Wrapping the value in double quotes preserves the full string: FRONTEND_URL="https://app.example.com#dashboard".

Why is the export prefix flagged as a warning?

The export keyword is valid in shell scripts and some .env parsers strip it, but Docker Compose and many dotenv implementations do not. A line like export SECRET_TOKEN=abc123 works in bash but leaves the literal export in the key name on other platforms. Remove the prefix and rely on the parser to inject the variable into the environment.

Does the validator detect hardcoded secrets?

Yes. Values that match known secret formats such as AWS Access Key IDs, GitHub personal access tokens, Slack tokens, Google API keys, OpenAI-style keys, and PEM private key headers are flagged as warnings. Keys whose names suggest credentials (password, secret, token, api_key) also receive an informational reminder to keep the file out of version control.

Can I validate .env files with comments and blank lines?

Yes. Lines that start with # are treated as comments and skipped. Blank lines are ignored. The validator counts only KEY=value pairs toward the parsed total and does not flag comments or blank lines as errors.

What is the BOM warning about?

A byte order mark (BOM) is a invisible UTF-8 signature that some editors add to the start of a file. Many .env parsers treat the BOM as part of the first key name, so the first variable silently fails to load. The validator warns when a BOM is detected so you can re-save the file without it.

Is my .env file uploaded to a server?

No. The entire validation pass runs in the browser tab. Database URLs, API keys, and internal service endpoints stay on your machine. There is no account, no history, and no network request in the validation path.