.ENV Inspector — Free Online Tool

Paste your .env file to validate format, detect exposed API keys and secrets, and generate a safe .env.example. All processing is 100% client-side.

Your secrets stay local: This tool runs entirely in your browser. Zero network requests are made — verified via DevTools Network tab.
🔍

Paste your .env file above

Detects secrets, validates format, and generates .env.example

What Does the .ENV Inspector Check?

The .ENV Inspector analyzes your environment variable file for three categories of issues: secret exposure risk, format problems, and completeness. It parses each line, classifies variables by sensitivity, and helps you generate a safe template file for your team.

Secret Pattern Detection

The inspector flags variables whose names match common patterns for sensitive credentials. Variables are classified as secrets when their key contains any of these patterns:

  • API credentials: API_KEY, API_SECRET, API_TOKEN, ACCESS_KEY, ACCESS_TOKEN
  • Authentication: PASSWORD, PASSWD, PWD, AUTH, BEARER, OAUTH, SESSION_SECRET
  • Cryptographic: PRIVATE_KEY, SECRET, HMAC, SALT, SIGNING_KEY, ENCRYPTION_KEY
  • Database: DATABASE_URL, DB_URL, MONGO_URI, POSTGRES_URL, MYSQL_URL, CONNECTION_STRING, DSN
  • Infrastructure: WEBHOOK_SECRET, CERTIFICATE, CREDENTIAL, REDIS_PASSWORD

Common .env Format Issues

  • Missing equals sign: Every variable must follow the KEY=VALUE pattern. Lines without = are invalid.
  • Invalid key names: Keys should only contain uppercase letters, numbers, and underscores. Keys starting with numbers or containing spaces are invalid in most environments.
  • Unquoted values with spaces: Values containing spaces should be wrapped in quotes: APP_NAME="My Application"
  • Inline comments: Some parsers do not support inline comments (PORT=3000 # web port). Put comments on their own line.
  • Trailing spaces: Trailing whitespace in values can cause subtle bugs, especially with passwords and tokens.

.env Security Best Practices

  • Always add .env to .gitignore: Run echo ".env" >> .gitignore before your first commit. Once a secret is in git history, it must be considered compromised — rotation is the only fix.
  • Commit .env.example instead: Document which variables are needed without exposing actual values. New team members copy this file and fill in their own secrets.
  • Use different credentials per environment: Production, staging, and development should each have separate API keys and database credentials. Never reuse production secrets in development.
  • Rotate secrets regularly: Treat secrets like passwords — rotate them periodically and immediately when someone with access leaves the team.
  • Use a secret manager in production: For production workloads, prefer dedicated secret management solutions like AWS Secrets Manager, HashiCorp Vault, or Doppler over .env files on disk.
  • Never log environment variables: Avoid printing process.env to logs, especially in production. Set up log filtering to redact sensitive patterns.

Frequently Asked Questions about .env Files

Is it safe to paste my .env file into this tool?

Yes — this tool runs entirely in your browser. No data is transmitted to any server. You can verify this by opening your browser's DevTools → Network tab while using the tool. You will see zero outgoing requests. The analysis happens locally in JavaScript and disappears when you close the tab.

What is a .env file and how does it work?

A .env (dotenv) file is a plain text file that stores environment variables for your application. Variables follow the KEY=VALUE format, one per line. Libraries like dotenv (Node.js), python-decouple (Python), or godotenv (Go) load these files at startup, making the variables available as environment variables in your process. This separates configuration from code — the same codebase runs in development, staging, and production with different .env files.

What's the difference between .env, .env.local, and .env.production?

Many frameworks (Next.js, Vite, Create React App) support multiple .env file variants with different loading priorities. .env is the default loaded in all environments. .env.local overrides .env and is ignored by git. .env.production and .env.development are environment-specific. .env.local always takes priority over environment-specific files. Check your framework's documentation for the exact loading order.

My .env file was accidentally committed to Git — what should I do?

Immediately rotate all exposed credentials — they should be considered compromised because git history is permanent even after deletion. Remove the file with git rm --cached .env, add .env to .gitignore, and force-push to overwrite history with git filter-branch or BFG Repo Cleaner. If the repo is public or has been cloned, assume all secrets are compromised regardless of history rewriting.

Related Developer Tools