.env ⇄ JSON / YAML Converter
Convert .env files to JSON or YAML and back, or turn them into a Kubernetes ConfigMap or Secret, a docker-compose environment: block, docker run -e flags, a GitHub Actions env: block or an AWS ECS environment array. The parser follows real dotenv rules and points out problems by line.
.env input
Output
.env syntax rules
A .env file is a list of KEY=value lines. There is no official standard, but Node's dotenv, python-dotenv, Docker Compose and most frameworks agree on the basics. This tool follows them:
- Blank lines and lines starting with
#are ignored. - An optional
exportprefix is allowed, so the same file can besourced by a shell. - Keys should use letters, digits and underscores and must not start with a digit. Dots and dashes are accepted by some loaders but not by shells, so they get a warning.
- Unquoted values are trimmed. A
#preceded by a space starts a comment:PORT=8080 # webis8080. - Single-quoted values are literal. Nothing inside is expanded:
'a\nb $HOME'stays exactly that. - Double-quoted values understand escapes:
\n,\r,\t,\"and\\. Both quote styles may span several lines, which is how PEM keys and certificates are usually stored. KEY=sets an empty string. If a key appears twice, the last value wins (and this tool warns you).
Quoting gotchas
- The
#trap. Node's dotenv ends an unquoted value at any#, soPASSWORD=abc#123becomesabc. Compose and python-dotenv keep it. Quote any value that contains#. - The
$trap. Docker Compose and dotenv-expand interpolate$VARand${VAR}in unquoted and double-quoted values. Use single quotes for literal dollar signs, or write$$inside a Compose file. The Compose output here escapes$for you. - Spaces around
=.KEY = valueworks with dotenv but breakssource .envin a shell. - When generating a .env file, this tool leaves simple values unquoted, wraps values with spaces or special characters in single quotes, and falls back to double quotes with escapes only when a value contains a newline or a single quote. That output reads back the same in every common loader.
Converting nested JSON and YAML
Environment variables are flat strings, so nested objects are flattened by joining keys: {"database": {"host": "db"}} becomes DATABASE_HOST=db. ASP.NET Core and many config libraries use a double underscore (Database__Host) as the separator because single underscores already appear inside names. Going the other way, Nest keys by rebuilds the object. Auto-type turns unquoted true, false, null and plain numbers into JSON types. Values with leading zeros, like ZIP codes, stay strings.
Never commit .env files
A .env file usually holds database passwords and API keys. Add it to .gitignore on day one and commit a .env.example with the same keys and dummy values instead. If a real secret ever reaches a Git repository, consider it leaked: rotate it, because removing the commit does not remove it from forks, clones and caches. Also keep .env out of Docker images with a .dockerignore entry.
Using these outputs
| Docker | docker run --env-file .env image reads the file directly (no quote processing, so keep values simple). The generated -e flags are shell-quoted for scripts. |
|---|---|
| Docker Compose | Paste the environment: block under a service, or point env_file: .env at the file. A .env next to compose.yaml is also used for ${VAR} interpolation in the Compose file itself. |
| Kubernetes | Apply the ConfigMap or Secret with kubectl apply -f, then load every key into a container with envFrom: [{configMapRef: {name: …}}] or secretRef. kubectl create secret generic my-app --from-env-file=.env does the same from the command line. |
| GitHub Actions | Put the env: block at workflow, job or step level. Store sensitive values under Settings → Secrets and variables → Actions and reference them as ${{ secrets.NAME }}, which is what the sensitive-key option generates. |
| AWS ECS | The environment array goes inside a container definition of the task definition. For secrets, use the secrets array with valueFrom pointing at Secrets Manager or SSM Parameter Store instead of plain values. |
Kubernetes Secrets are base64, not encryption
The values in a Secret's data section are only base64-encoded. Anyone who can read the YAML can decode them with base64 -d. That is why a generated Secret file must never be committed as-is. Protect Secrets with RBAC, enable encryption at rest in the cluster, and keep the source of truth in a secret manager or encrypt the files with Sealed Secrets, SOPS or External Secrets Operator. This tool encodes values as UTF-8 before base64, matching kubectl.
Is my data safe?
Yes. Parsing and conversion run entirely in your browser with JavaScript. Nothing you paste is uploaded or stored. Use Mask values in preview when sharing your screen.