Convert JSON to .env
Environment Variables

Environment variables in four steps

No account. No upload. No nonsense.

Related JSON tools

Common questions answered

Converting JSON to .env format

.env files store environment variables as KEY=VALUE pairs, one per line. They are the standard way to configure secrets (API keys, database URLs, feature flags) without hardcoding. Tools like dotenv (Node.js), python-dotenv, and Docker Compose read .env files automatically, making them universal for application configuration.

This tool flattens a JSON object into .env format. Top-level keys are converted to UPPER_SNAKE_CASE, nested objects flatten with underscore separators (database.host → DATABASE_HOST), and values are quoted when they contain spaces or special characters. Arrays are joined with commas.

{
  "database": {
    "host": "localhost",
    "port": 5432,
    "name": "myapp"
  },
  "apiKey": "sk-abc123",
  "debug": true
}

DATABASE_HOST=localhost
DATABASE_PORT=5432
DATABASE_NAME=myapp
API_KEY=sk-abc123
DEBUG=true

Get the most out of this tool

• Use UPPER_SNAKE_CASE for environment variable names — the universal convention across operating systems.
• Never commit .env files to version control — add .env to .gitignore and share a .env.example template.
• Nested JSON flattens to underscore keys: {"db":{"host":"localhost"}} becomes DB_HOST=localhost.

JSON to .env conversion for twelve-factor apps

The .env file format is the standard way to define environment variables for local development, popularized by the dotenv library (available for Node.js, Python, Ruby, PHP, and Go). It stores key-value pairs as KEY=value on each line, loaded into the process environment at startup. Converting JSON configuration to .env format is a common need when migrating from one configuration style to another or when sharing configuration with tools that expect environment variables.

The twelve-factor app methodology (12factor.net) recommends storing configuration in environment variables rather than in code or config files. This makes applications deployable across different environments (development, staging, production) by changing only the environment, not the code. Converting a JSON configuration object to environment variables is the first step in adopting the twelve-factor configuration principle for an existing application.

Nested JSON objects require special handling when converting to environment variables. Environment variable names are flat — they cannot contain the dots or brackets used for nested access in JSON. The standard convention is to use double underscores to represent nesting depth: {"database": {"host": "localhost"}} becomes DATABASE__HOST=localhost. Some platforms use single underscores, and some use a different separator entirely. The converter follows the double-underscore convention by default.

Variable naming conventions for environment variables typically use SCREAMING_SNAKE_CASE — all uppercase letters with underscores separating words. This matches the convention used by most cloud platforms (AWS, GCP, Azure), Docker, Kubernetes secrets, and CI/CD platforms. The converter automatically uppercases all key names when converting to .env format, producing environment variable names that match the platform expectations.

Security is a critical consideration with .env files. They frequently contain API keys, database passwords, and other secrets. The .env file should always be in .gitignore — never committed to version control. Instead, a .env.example file (with placeholder values, no real secrets) is committed, showing which variables are required without exposing their values. This converter helps create both the .env and .env.example files from a JSON configuration document.

Docker and Docker Compose natively support .env files through the --env-file flag and the env_file configuration option. Kubernetes supports loading .env-format files as ConfigMaps and Secrets. AWS ECS and Lambda support environment variable injection from .env-like sources. The .env format's universality makes it the practical lowest-common-denominator for environment configuration across all modern deployment platforms.

When developers use this tool

Additional frequently asked questions