Environment File Parser

Environment files (.env) store configuration as key-value pairs, keeping secrets and settings separate from code. Popularized by the twelve-factor app methodology, they're used across Node.js, Python, Ruby, and other ecosystems. This tool parses .env files and displays variables in a structured view.

Specifications

Common Use Cases

  • Inspect application environment configuration
  • Validate .env file syntax before deployment
  • Compare environment files between environments (dev, staging, prod)
  • Convert environment variables to JSON for documentation
  • Review configuration without exposing to logs

Features

  • Parse KEY=value pairs with various formats
  • Handle quoted values (single and double quotes)
  • Skip comments (#) and empty lines
  • Show/Hide secrets toggle (masks keys matching password, token, api, secret, etc.)
  • Convert to JSON and YAML for programmatic use
  • Comment count display

Examples

Application Configuration

Try it →

A typical .env file with database and API settings.

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

# API Keys
API_KEY="sk-1234567890"
SECRET_KEY='super-secret-value'

Tips

  • Never commit .env files to version control. Use .env.example instead.
  • Quoted values preserve leading/trailing whitespace.
  • Some implementations support variable expansion: ${VAR}.
  • Use separate .env files per environment: .env.development, .env.production.

Understanding Environment File

Environment variable files (.env) store application configuration as simple KEY=VALUE pairs, one per line. The format was popularized by the twelve-factor app methodology, which advocates strict separation of configuration from code. Rather than hardcoding database URLs, API keys, and feature flags, applications read them from environment variables, and .env files provide a convenient way to set those variables during development.

The dotenv library, originally for Ruby and later ported to Node.js, Python, PHP, and virtually every ecosystem, reads .env files and injects values into the process environment. The format supports unquoted values (DATABASE_HOST=localhost), double-quoted values with escape sequences (MESSAGE="Hello\\nWorld"), and single-quoted values treated literally (REGEX='^\\d+$'). Comments begin with # and blank lines are ignored.

A critical practice is to never commit .env files to version control since they typically contain secrets. Instead, projects include a .env.example listing all required variables with placeholder values. CI/CD systems and hosting platforms provide their own mechanisms for setting environment variables securely.

Variable expansion (referencing other variables with \${VAR} syntax) is supported by some dotenv implementations. Docker Compose supports it natively. When relying on expansion, verify that your specific dotenv implementation supports it, as behavior varies across languages.

The .env file typically contains secrets like database passwords, API keys, and encryption keys. Committing these to git exposes them to anyone with repository access, and they persist in git history even after deletion. Add .env to .gitignore and use a .env.example with placeholder values to document required variables. Double-quoted values interpret escape sequences (\\n becomes a newline), while single-quoted values are treated as raw literals with no escape processing. Unquoted values are trimmed of trailing whitespace and stop at the first # character, which is treated as an inline comment.

Managing multiple environments typically involves separate .env files: .env for defaults, .env.local for machine-specific overrides (not committed), and .env.development or .env.production for environment-specific values. Frameworks like Next.js, Vite, and Create React App load these in a specific priority order. For Docker, Compose supports env_file to load variables from a file and the environment key to set them directly. The Compose .env file in the project root is used for variable substitution in docker-compose.yml itself. Build-time ARG variables are different from runtime ENV variables and should not contain secrets.

← Back to all tools