YAML to .env Converter

Q: How does nesting become a flat variable name?

Each level is joined with an underscore and the whole name is upper-cased, so a host key inside a database block becomes DATABASE_HOST. That is the convention every twelve-factor application and container platform uses, which is why it is the default. The separator is configurable because some systems prefer a double underscore — .NET in particular reads DATABASE__HOST as nested configuration — and picking the wrong one means your application never sees the value.

Q: When do values get quoted?

Only when they need it, because unnecessary quotes end up as part of the value in some parsers. A value is quoted if it contains a space, a hash, a quote character, a newline or a leading or trailing space. The hash matters more than people expect: in most .env parsers everything after an unquoted # is treated as a comment, so a password containing one is silently truncated at that point — which produces an authentication failure that looks nothing like a quoting problem.

Q: What happens to a list?

It becomes a single comma-separated value, because .env has no concept of an array — every value is a string. So a list of three allowed hosts becomes ALLOWED_HOSTS=a,b,c and your application splits it on the comma. If the values themselves contain commas that will not work, and the honest answer is that such data does not belong in an environment variable; keep it in the YAML and read the file directly, or move to indexed keys.

Q: Are comments carried over?

No, and this is worth understanding before you paste the output over a file you have annotated. Conversion works by parsing the YAML into data, and comments are not part of that data — they exist only in the text. Both formats support comments, but the round trip goes through a structure that has no room for them. Generate into a new file, or copy the variables you need across rather than replacing wholesale.

Q: Can it go the other way, from .env back to YAML?

Yes, and the underscore-splitting is inevitably a guess. DATABASE_HOST clearly nests as host under database, but MAX_RETRIES could equally be a single key called max_retries or a retries key under max. The tool splits on the separator consistently and shows you the result so you can check it, but a name that was never nested to begin with may come back nested. Reviewing the output matters more in this direction than the other.

Q: Should configuration live in YAML or in environment variables?

The usual split is that structure belongs in YAML and secrets belong in the environment. YAML handles nesting, lists and comments, so it is the better home for anything a person reads and edits. Environment variables are flat strings, but they are what container platforms and CI systems inject, and they keep credentials out of files that might get committed. Converting between the two is normally about moving a specific subset across, not translating an entire configuration.

Flatten nested YAML into environment variables and convert .env files back to YAML, with values quoted only where they need it.

YAML

Nesting separator

Name prefix (optional)

.env

Conversion runs entirely in your browser. Comments are not carried across in either direction — they are not part of the parsed data.

What It Does

YAML nests and .env does not, so this flattens one into the other. Each level of nesting joins with an underscore and the name is upper-cased, giving the DATABASE_HOST convention that twelve-factor applications and container platforms expect. Lists collapse into comma-separated strings, because an environment variable is always a single string. The care is in the quoting: values are quoted only when they need to be, since unnecessary quotes become part of the value in some parsers — but a value containing a hash absolutely must be quoted, because most .env parsers treat everything after an unquoted hash as a comment and would silently truncate a password there. It converts back to YAML too, where the underscore-splitting is a genuine guess worth reviewing.

When to Use It

A configuration file is in YAML and your deployment platform only accepts environment variables.
You are containerising an application and need the existing config as a flat list for a Dockerfile or a compose file.
A CI system takes secrets as environment variables and you have them in a YAML file locally.
You are moving from environment variables to a config file and want a starting YAML structure.
You need to check exactly how a nested key will appear as a variable name before wiring it up.

Worked Examples

database:
  host: localhost
  port: 5432
debug: true

The basic flattening. Two levels become DATABASE_HOST and DATABASE_PORT, while the top-level key becomes plain DEBUG. None of these values need quoting, so none get it.

app:
  secret: "pa#word with spaces"
  name: My App

The quoting case that matters. Both values are quoted — one for the space, one because that hash would otherwise start a comment and silently truncate the secret, producing an authentication failure that looks nothing like a quoting bug.

allowed_hosts:
  - example.com
  - api.example.com

A list becomes one comma-separated value, since .env has no arrays. Your application splits it on the comma — which is fine here, and would not be if the values themselves contained commas.

Features

Nested YAML flattened to environment variable names

Configurable separator including .NET double underscore

Values quoted only when they actually need it

Hash and space handling that prevents silent truncation

Lists collapsed to comma-separated values

Reverse conversion from .env back to nested YAML

Key name prefix option

Variable count and nesting depth reported

Warning when comments would be lost

Runs entirely in your browser

How to Use

1. Choose a direction — YAML to .env, or .env to YAML. 2. Paste your configuration. 3. The converted output appears immediately. 4. Set the separator to double underscore if you are targeting .NET. 5. Copy the result into a new file rather than over an annotated one, since comments do not survive.

Common Mistakes

Leaving a value containing a hash unquoted. Most .env parsers treat the rest of the line as a comment, so the value is silently truncated and the failure appears somewhere else entirely.
Quoting everything to be safe. Some parsers include the quotes in the value, so a password arrives with quote marks attached and authentication fails.
Using a single underscore for .NET. It reads a double underscore as nesting, so DATABASE_HOST and DATABASE__HOST mean different things and only one works.
Expecting comments to survive. Conversion goes through parsed data, which has no room for them — generate into a new file rather than overwriting an annotated one.
Putting structured data in an environment variable. A list of values containing commas cannot round-trip, and that is a signal the data belongs in a file rather than the environment.

Frequently Asked Questions

How does nesting become a flat variable name?

When do values get quoted?

What happens to a list?

Are comments carried over?

Can it go the other way, from .env back to YAML?

Should configuration live in YAML or in environment variables?