DevBolt
Processed in your browser. Your data never leaves your device.

How do I validate a .env file online?

Paste your .env file and the tool checks for syntax errors, duplicate keys, naming convention violations, exposed secrets (passwords, API keys), and missing quotes. Use Compare mode to diff .env vs .env.example for missing or extra variables. Export a clean .env.example template. Everything runs in your browser.

Validate .env file
Input
DATABASE_URL=postgres://localhost/db
API_KEY=sk-abc123
PORT=3000
DEBUG=true
SECRET=
Output
✓ 4 valid variables
⚠ 1 issue:
  SECRET — empty value
  (may cause runtime errors)

Variables: 5 total
Types: 2 URLs, 1 number,
  1 boolean, 1 empty
← Back to tools

.env File Validator

Validate .env files for syntax errors, duplicate keys, security risks, and best practices. Export a sanitized version or .env.example template.

About .env File Validation

A .env file stores environment variables as key-value pairs. They are used to configure applications without hardcoding sensitive data like API keys and database credentials.

What we check:

  • Syntax— valid KEY=VALUE format, proper quoting, no spaces around "="
  • Variable names — must match [a-zA-Z_][a-zA-Z0-9_]*
  • Duplicate keys— flags variables defined more than once
  • Empty values— warns about variables with no value assigned
  • Placeholder values— detects TODO, changeme, and similar placeholders
  • Security— flags real secrets in sensitive variables (passwords, tokens, API keys)
  • Embedded credentials— warns about URLs containing username:password
  • Inline comments— detects potential unquoted inline comments

Export options:

  • .env.example— keys only, no values. Safe to commit to version control.
  • Sanitized copy — all values replaced with <REDACTED> for sharing without exposing secrets.

Everything runs in your browser — no data is sent over the network.

Tips & Best Practices

Pro Tip

Compare .env against .env.example on every deploy

Your .env.example should list every variable your app needs (with empty or example values). Validate that production .env has all required keys before starting the app. Missing variables cause runtime crashes that are hard to debug.

Common Pitfall

Quoted and unquoted .env values behave differently

In most .env parsers, VALUE=hello world sets VALUE to 'hello world' (with space). But VALUE="hello world" includes the quotes in some parsers and strips them in others. Be consistent: always quote values containing spaces or special characters.

Real-World Example

Use dotenv-vault or SOPS for team .env sharing

Sharing .env files via Slack, email, or git is insecure and error-prone. Tools like dotenv-vault encrypt .env files for safe version control, while SOPS (by Mozilla) encrypts individual values. Both support team key rotation.

Security Note

Never commit .env files to git — add them to .gitignore immediately

Even private repos can be leaked, forked, or accessed by contractors. Committed .env files with API keys are the #1 cause of credential leaks in GitHub repos. If you accidentally committed one, rotate ALL the secrets — git history is permanent.

Frequently Asked Questions

How do I validate a .env file for errors?
Paste your .env file contents into DevBolt's ENV Validator and it checks for syntax errors, duplicate keys, security concerns, and formatting issues. The tool identifies unquoted values containing spaces, missing equals signs, duplicate variable names, and values with unintended comments. It also flags potential security issues like variables named PASSWORD or SECRET with weak or placeholder values. The validator runs entirely in your browser, so your environment variables including secrets and API keys are never transmitted to any server.
What are common mistakes in .env files?
Frequent .env mistakes include: forgetting to quote values with spaces, using inline comments incorrectly (some parsers treat # as part of the value), duplicate keys where the last definition silently wins, trailing whitespace becoming part of values, accidentally committing .env to version control, using $VAR expansion when the parser does not support it, and leaving placeholder values in production. Different parsers (dotenv for Node.js, python-dotenv, Docker) have slightly different rules causing values to behave differently across environments.
Should I commit .env files to Git?
Never commit .env files containing real secrets to Git. Add .env to your .gitignore file. Instead, commit an .env.example with placeholder values documenting which variables are required. For team environments, use secret management tools like Doppler, 1Password, HashiCorp Vault, or your cloud provider's secret manager. For CI/CD, inject environment variables through the pipeline configuration. If secrets were accidentally committed, rotate them immediately since they remain in Git history even after deletion.

Related Inspect Tools