.env File Validator

Your app crashes on deploy with DATABASE_URL is undefined. You open .env.production — the variable is there. Then you spot it: DATABASE_URL =postgres://... with a space before the =. Or worse, you have API_KEY defined twice — the second one silently overwrites the first with a stale value. Or staging works but production doesn’t because .env.production is missing REDIS_URL that .env.staging has. You need a validator that catches these before deploy, and a comparator to diff two env files.

Why This Validator (Not the Environment Variable Generator)

PureDevTools has an Environment Variable Generator for building new .env files from scratch with framework templates. This tool is for validating existing .env files — catch syntax errors (spaces in keys, unquoted values with spaces, missing =), detect duplicate keys, and compare two .env files side-by-side to find missing variables. Everything runs in your browser; your secrets are never sent anywhere.

What Is a .env File?

A .env file is a plain-text configuration file used to store environment variables outside of your source code. It follows a simple KEY=VALUE format and is loaded by your application at runtime — keeping secrets like API keys, database credentials, and service URLs out of your codebase.

# Database
DATABASE_URL=postgres://localhost:5432/myapp
DATABASE_POOL_SIZE=10

# External APIs
STRIPE_SECRET_KEY=sk_live_...
SENDGRID_API_KEY=SG.xxx

# Feature flags
ENABLE_DARK_MODE=true

Libraries like dotenv (Node.js), python-dotenv (Python), and Vite’s built-in support load these files automatically in development.

.env Syntax Rules

Key Format

Keys must follow these rules:

• Start with a letter (A–Z, a–z) or underscore (_)
• Contain only letters, digits (0–9), and underscores
• No spaces, hyphens, or special characters in the key name

By convention, environment variable keys are UPPER_SNAKE_CASE (e.g., DATABASE_URL, API_SECRET_KEY).

VALID_KEY=value        # ✅ Valid
_PRIVATE_KEY=value     # ✅ Valid (underscore prefix is allowed)
myLowercaseKey=value   # ⚠️ Warning: not UPPER_SNAKE_CASE (works but unconventional)
2INVALID=value         # ❌ Error: starts with a digit
KEY WITH SPACES=value  # ❌ Error: spaces in key name

Value Format

Values can be unquoted, single-quoted, or double-quoted:

UNQUOTED=simple_value
DOUBLE_QUOTED="value with spaces"
SINGLE_QUOTED='another value'
EMPTY_VALUE=

Quoting rules:

• Unquoted values: everything after = up to an inline comment or end of line
• Double-quoted values: support escape sequences (\n, \", \\)
• Single-quoted values: treated literally, no escape sequences
• Values with spaces must be quoted to avoid ambiguity across different loaders

Comments

Lines starting with # are comments. Inline comments are supported in most loaders:

# Full-line comment
API_KEY=abc123  # inline comment (stripped by most parsers)

Common .env Issues This Tool Detects

.env.example: The Template File

It is best practice to commit a .env.example file to your repository. This file has all the same keys as your .env but with empty or placeholder values — documenting which variables are required without exposing real secrets.

# .env.example — copy to .env and fill in the values
DATABASE_URL=
API_KEY=your_api_key_here
STRIPE_SECRET_KEY=

New team members clone the repo, copy .env.example to .env, fill in their credentials, and they are ready to go.

This tool’s Export as .env.example feature strips all values from your .env and preserves comments and key structure, producing a ready-to-commit template.

Comparing .env Files

Keeping .env files in sync across environments (development, staging, production) or across team members is a common pain point. The compare feature helps you:

• Find missing keys: see which variables are in .env.example but missing from your local .env
• Spot value differences: compare configuration between two environments (use placeholder values if comparing sensitive configs)
• Audit additions: see which custom keys you added that are not in the template

Comparison Status Indicators

Organizing .env Files by Prefix

As applications grow, .env files can contain dozens of variables. Grouping related variables by prefix improves readability:

# Database
DATABASE_URL=postgres://localhost/myapp
DATABASE_POOL_SIZE=10
DATABASE_SSL=true

# Redis
REDIS_URL=redis://localhost:6379
REDIS_TTL=3600

# Auth
AUTH_SECRET=...
AUTH_TOKEN_EXPIRY=86400

The Group by Prefix feature automatically organizes your variables into sections based on the first word before the underscore.

Security Best Practices

• Never commit .env to version control — add it to .gitignore
• Commit .env.example with empty or placeholder values
• Rotate secrets immediately if a .env file is accidentally committed
• Use different values per environment — never share production credentials with development
• Consider a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) for production environments

Frequently Asked Questions

Is my .env content sent to a server? No. All parsing, validation, and comparison happens entirely in your browser using JavaScript. Your environment variables and secrets never leave your device.

What .env loaders does this tool validate against? This tool validates the common subset supported by most loaders: dotenv (Node.js), python-dotenv (Python), Vite, Laravel’s DotEnv, and similar. Edge-case behavior (multiline values, shell variable expansion, export prefix) varies by loader — this tool flags the most common interoperability issues.

Can I validate Docker Compose env_file or Kubernetes ConfigMaps? Docker Compose env_file uses the same KEY=VALUE format and is compatible with this validator. Kubernetes ConfigMap YAML files use a different format and are not directly validated here.

Why does the tool warn about lowercase keys? By convention — not strict requirement — environment variable keys are UPPER_SNAKE_CASE. Most loaders accept lowercase keys, but they are easy to miss in large files and may conflict with shell variable naming conventions. The warning is advisory, not an error.

How are duplicate keys handled? Most loaders use the first occurrence and ignore subsequent definitions of the same key, though some use the last. The validator flags duplicates as warnings so you can decide which to keep.

What is the difference between .env and .env.local? Many frameworks (Next.js, Vite, Create React App) support multiple .env files with different loading priorities: .env (always loaded), .env.local (local overrides, gitignored), .env.development, .env.production. The .env.local file is typically for developer-specific overrides. This validator works with all of them since they share the same syntax.