.env file content

.env.example (optional — checks for missing keys)

What is .env File Validator?

A .env (dotenv) file stores environment variables as KEY=VALUE pairs, loaded at runtime to configure applications without hardcoding secrets in source code. Popular frameworks like Next.js, Django, Laravel, and Rails all rely on .env files for configuration. Despite their simplicity, .env files are prone to subtle formatting errors: duplicate keys where the last value wins unpredictably, unquoted values containing spaces that get truncated, and inline comments that silently become part of a value. These issues can cause bugs that are extremely difficult to trace in production. This validator catches those problems instantly by checking syntax, detecting duplicates, flagging empty values, and comparing against your .env.example template.

How to Use

Paste your .env file content into the top editor — you can include comments, blank lines, and any key-value pairs.
Optionally paste your .env.example file in the bottom editor to check for missing keys that your application expects.
Click "Validate" to see all issues with line numbers — errors (red) are definite problems, warnings (yellow) are potential issues.
Review each issue and fix it in your actual .env file, then re-validate until all errors are resolved.
Use the stats bar to quickly see how many keys were parsed and how many problems were found.

Why Use This Tool?

Find duplicate keys before they cause unpredictable runtime behavior where different parsers resolve conflicts differently

Catch empty values that might cause null reference errors or default to unexpected values in your application

Detect invalid key names with special characters or spaces that some dotenv parsers reject silently

Compare against .env.example to ensure all required variables are set before deploying to production

Identify unquoted values containing spaces that may be truncated or misinterpreted by shell environments

All validation runs in your browser — your secrets never leave your device

Tips & Best Practices

Key names should use UPPER_CASE with underscores by convention — this matches how they appear in code via process.env.MY_VAR
Quote values that contain spaces: MY_VAR="hello world" — without quotes, some parsers only capture the first word
Inline comments can break some parsers — use a separate comment line above the variable instead
Never commit your actual .env file to version control; always commit .env.example with placeholder values only
Use different .env files per environment: .env.local for development, .env.production for deployment, .env.test for testing

Frequently Asked Questions

Why does my .env file cause bugs in production?

Common causes: duplicate keys (last value wins in most parsers but first in others), missing quotes around values with special characters, empty required values, or keys present in .env.example but missing from the deployed .env file. Run this validator before every deployment to catch these issues early.

Are my .env file contents safe to paste here?

Yes. All validation runs entirely in your browser using JavaScript. Your .env contents never leave your device and are not sent to any server. You can verify this by checking the browser network tab — no requests are made when you click Validate.

What is .env.example for?

.env.example (also called .env.template or .env.sample) is a version-controlled file listing all required environment variable names with placeholder or example values. It documents the variables needed to run the app without exposing real secrets. New developers copy it to .env and fill in real values.

Can I have comments in .env files?

Yes. Lines starting with # are treated as comments and ignored by dotenv parsers. Inline comments (VALUE=something # note) are risky — some parsers include the "# note" as part of the value. It's safer to put comments on their own line above the variable they describe.

When should I NOT use .env files?

Avoid .env files for managing secrets in large-scale or containerized deployments where orchestration platforms (Kubernetes, AWS Secrets Manager, HashiCorp Vault) provide better secret management with rotation, auditing, and access control. Also avoid .env files when you need type coercion — dotenv only stores strings, so numbers and booleans must be parsed manually in your application code.

What happens with duplicate keys?

Behavior varies by parser: most implementations use the last occurrence (e.g., Python dotenv, Node dotenv), but some use the first. This inconsistency means duplicate keys can cause different behavior in development versus production. The validator always flags duplicates as errors so you can resolve them explicitly.

Real-world Examples

Catching a Duplicate API Key

A developer accidentally pasted the same API key twice with different values. The last value silently overrides the first in most parsers, causing authentication to fail against the intended service.

Input

API_KEY=sk-prod-abc123
API_KEY=sk-test-wrong456

Output

Error: Duplicate key "API_KEY" found on lines 1, 2

Detecting Missing Required Variables

Comparing against .env.example reveals that SECRET_KEY and REDIS_URL are defined in the template but missing from the actual .env file — a common cause of crashes after deployment.