Env Variable Manager

Parse .env files into a table or diff two environments side by side.

What It Does

This tool has two modes. Parse mode takes a raw .env file and displays it as a clean, searchable table — useful for auditing which variables are defined and what their values are. Diff mode compares two .env files side by side, highlighting variables that are added, removed, or have different values between environments. Everything runs in your browser.

.env File Syntax

# Database
DB_HOST=localhost
DB_PORT=5432
DB_NAME=myapp_dev
DB_USER=postgres
DB_PASS="p@ssw0rd!"   # quotes optional

# App config
NODE_ENV=development
PORT=3000
LOG_LEVEL=debug

# Empty values are valid
OPTIONAL_FEATURE=

Diff Color Legend

  • Green — Key exists only in the second file (added in new env)
  • Red — Key exists only in the first file (removed in new env)
  • Yellow / Orange — Key exists in both but values differ
  • Neutral — Key and value are identical in both files

Best Practices for .env Management

  • Always add .env to your .gitignore — never commit secrets to version control
  • Commit a .env.example with all variable names but placeholder values so new developers know what to configure
  • Use this diff tool before deployments to verify that all required variables are present in the target environment
  • Prefix variables by service or concern (DB_, REDIS_, AWS_) to keep large .env files organized
  • For production, prefer a secrets manager over .env files — they offer rotation, auditing, and access control

Frequently Asked Questions

What is the .env file format?
A .env file stores environment variables as KEY=VALUE pairs, one per line. Lines starting with # are comments and are ignored. Values can be optionally wrapped in single or double quotes. The format is not standardized — implementations vary slightly between dotenv libraries, but the core KEY=VALUE syntax is universal.
How does the diff mode help when comparing environments?
The diff view compares two .env files (for example, .env.development vs .env.production) and color-codes each variable: green for keys only in the second file, red for keys only in the first, yellow for keys present in both but with different values, and neutral for identical entries. This makes it easy to spot missing variables before a deployment.
Is it safe to paste sensitive .env values into this tool?
The tool runs entirely in your browser — no data is sent to any server. Your environment variables never leave your device. That said, as a general security practice, avoid using real production secrets in any browser-based tool. Use redacted or test values when possible.
How are quoted values and inline comments handled?
Values wrapped in double or single quotes are parsed with the quotes stripped. Inline comments (text after a # that follows the value) are stripped from the value. For example: API_KEY="abc123" # production key parses to API_KEY = abc123. Empty lines are ignored.
What is the best practice for managing .env files across environments?
Keep a .env.example (or .env.template) file in version control with all variable names but no real values. Each environment gets its own .env file that is never committed to git. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) for production secrets rather than .env files on servers.