.env Input
Results
Paste your .env content and click Validate
Lint your .env file for naming, security, and structure issues
← devnestioPaste your .env content and click Validate
Environment Variable Validator checks your .env files and environment variable definitions for common issues: missing required variables, type mismatches, malformed URLs or connection strings, insecure default values, and syntax errors. Paste your .env file content or upload it to get a structured validation report with severity levels (error, warning, info) and suggestions for fixing each issue.
Environment variables are the standard way to configure applications without hardcoding secrets or environment-specific settings. The .env file format (popularized by the dotenv npm package) stores KEY=VALUE pairs. Best practices: never commit .env files to version control (add to .gitignore), use .env.example as a documented template, validate all required variables at application startup, and separate concerns (DATABASE_URL, API_KEY, PORT should be distinct variables).
Common .env pitfalls: variables without quotes when values contain spaces, shell special characters in values ($ # = require escaping or quoting), accidentally committing secrets (use git-secrets or gitleaks in CI), using weak defaults for production (DEFAULT_PASSWORD=admin123), and missing validation allowing applications to start with incomplete configuration and fail at runtime.
Missing required var
Result: DATABASE_URL= (empty value) -> Error: Required variable DATABASE_URL is not set
Insecure default
Result: SECRET_KEY=changeme -> Warning: Secret key uses a weak default value
Malformed URL
Result: REDIS_URL=localhost:6379 -> Warning: Missing protocol prefix, should be redis://localhost:6379
What is the .env file format and how does dotenv parse it?
The .env file format: KEY=VALUE pairs, one per line. Comments: lines starting with # are ignored. Quotes: values can be unquoted (VALUE), single-quoted ('VALUE -- no interpolation), or double-quoted ("VALUE -- supports \n escape sequences"). Multiline values: supported inside double quotes. Variable interpolation: $VARIABLE or ${VARIABLE} in double-quoted values (supported by some parsers, not all). Empty value: KEY= means the variable exists but is empty. Leading/trailing spaces around = are stripped. dotenv (Node.js) and python-dotenv both support this format with minor differences.
What variables should never go in a .env file committed to git?
Never commit: API keys (AWS, Stripe, Twilio, SendGrid, etc.), database passwords, OAuth client secrets, JWT signing secrets, encryption keys, SMTP credentials, any key or password. Safe to commit: .env.example (template with placeholder values), FEATURE_FLAG variables (non-sensitive toggles), PORT=3000, LOG_LEVEL=info, NODE_ENV=development, public API base URLs (no keys). Use a secret manager for production: AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Doppler, or 1Password Secrets Automation.
How do I prevent .env files from being committed to git?
Add to .gitignore: .env, .env.local, .env.production, .env.*.local (match all environment-specific files). Check if .env is already tracked: git ls-files .env -- if it shows a result, untrack it: git rm --cached .env. Check history for exposed secrets: git log --all -p -- .env (view historical content). If secrets were committed: consider them compromised -- rotate all keys immediately, then use git-filter-repo or BFG Repo-Cleaner to remove from history. For ongoing protection: add git-secrets or gitleaks as a pre-commit hook.
How should I validate environment variables in a Node.js app?
Best practice: validate and parse all env vars at startup before the app starts accepting requests. Options: envalid (npm package): const env = cleanEnv(process.env, {DATABASE_URL: url(), PORT: port({default: 3000}), API_KEY: str()}); -- throws on missing/invalid. zod: const envSchema = z.object({DATABASE_URL: z.string().url(), PORT: z.coerce.number().default(3000)}); const env = envSchema.parse(process.env);. This approach catches misconfiguration at startup (not at the moment a feature is used), making errors obvious and fast to debug.
What is the difference between .env, .env.local, and .env.production?
Common .env file conventions (used by Next.js, Vite, Create React App, and similar): .env -- base variables for all environments, committed to git (non-sensitive only). .env.local -- local overrides, never committed (personal dev settings). .env.development -- development-specific variables, committed. .env.production -- production-specific variables, committed (without secrets). .env.development.local / .env.production.local -- local overrides for specific environments, never committed. Load order (Next.js example): .env.local takes priority over .env. Environment-specific files (.env.production) take priority over .env.