Staaarter Tools

ENV to YAML

Paste .env-file syntax, one KEY=value line at a time, with # comments and optional quoted values, and get back a flat YAML mapping with the same keys, ready to drop into a YAML-based config or secrets file. A free online tool from Staaarter, right in your browser.

Runs locallyUpdated 2026-07-26
conversionconfigurationenvironment-variables

Overview

Introduction

.env files are the standard way most Node, Python, Ruby, and PHP projects keep local environment variables and secrets out of source control, but plenty of deployment tooling (Kubernetes manifests, CI pipelines, config management) expects those same values in YAML instead. This tool converts one format to the other directly.

It's a small, hand-written line-oriented parser, no npm dependency needed, since .env syntax is simple enough not to warrant one.

What Is ENV to YAML?

An ENV-to-YAML converter reads .env-style text one line at a time, extracts each KEY=value pair (handling quoted values and comments along the way), and builds a single flat JavaScript object.

That object is then serialized as YAML using the same stringifier every other tool in this category uses, so the result matches this site's usual formatting conventions.

How ENV to YAML Works

Each line is trimmed; blank lines and lines starting with # are skipped. The remaining lines are split at their first =, with an optional leading export prefix on the key stripped (a shell-compatibility convenience some .env files use).

The value portion is then classified: a leading " starts a double-quoted value (scanned for its closing quote with backslash-escape awareness, then unescaped), a leading ' starts a single-quoted value (scanned literally, no escaping), and anything else is treated as unquoted, with a trailing # comment (if any) stripped before trimming.

When To Use ENV to YAML

Use it when migrating environment variables defined in a .env file into a YAML-based Kubernetes ConfigMap, GitHub Actions workflow, or similar deployment config.

It's also useful for quickly turning a flat list of env vars into YAML for documentation or for feeding into another tool in this category.

Often used alongside INI to YAML, HOCON to YAML and YAML Formatter & Prettifier.

Features

Advantages

  • Handles both double- and single-quoted values with the correct escaping rules for each, not just bare unquoted text.
  • Strips trailing comments only on unquoted values, so a literal # inside a quoted value is preserved rather than truncating it.
  • Reports a clear, line-numbered error for any line that doesn't fit KEY=value syntax.
  • Runs entirely client-side, so secrets and environment values never leave your browser.

Limitations

  • Every value is kept as a YAML string, since .env has no native type system, so numeric- or boolean-looking values are quoted in the output rather than converted to real numbers or booleans.
  • Multi-line values (a value that spans more than one physical line) aren't supported, since standard .env syntax doesn't define them either.
  • Variable expansion (referencing another variable inside a value, like KEY=$OTHER_KEY) is not resolved, the referenced text is kept as a literal string.

Examples

Quoted and unquoted values, with a trailing comment stripped

Input

DB_HOST=localhost
DB_PASSWORD="s3cr3t!"
DB_PORT=5432 # default postgres port

Output

DB_HOST: localhost
DB_PASSWORD: s3cr3t!
DB_PORT: "5432"

The trailing comment on DB_PORT is removed, and the numeric-looking value is quoted so it stays a string once parsed back.

Best Practices & Notes

Best Practices

  • Use double quotes for any value containing a literal # so it isn't mistaken for the start of a trailing comment.
  • Review numeric- or boolean-looking values in the output (like "5432" or "true"), they're intentionally quoted strings; convert specific ones by hand if your target YAML config expects a real number or boolean.
  • Keep the original .env file until you've confirmed the converted YAML is being read correctly wherever you're deploying it.

Developer Notes

The parser processes one line at a time with no lookahead, so it can't support multi-line values; the export keyword is stripped as a convenience since some .env files are written to be safely `source`-able in a shell. Quoted-value scanning is escape-aware for double quotes only, matching how most dotenv implementations treat single quotes as fully literal.

ENV to YAML Use Cases

  • Migrating a project's .env file into a Kubernetes ConfigMap or Secret manifest
  • Converting environment variables into YAML for a CI/CD pipeline configuration file
  • Documenting a service's required environment variables in a structured YAML format
  • Feeding .env-derived values into another YAML-based tool in this category

Common Mistakes

  • Expecting a value like "true" or "5432" to become a real YAML boolean or number, it stays a quoted string, since .env has no type system to infer from.
  • Using an unescaped # inside an unquoted value and being surprised the rest of the line was silently dropped as a comment.
  • Assuming multi-line values or variable expansion (like ${OTHER_VAR}) are resolved, neither is supported, they're passed through or rejected as unsupported line syntax.

Tips

  • If a value needs to contain a literal #, wrap it in double or single quotes so it isn't stripped as a trailing comment.
  • Use Sort YAML afterward if you want environment variables listed alphabetically instead of in .env file order.
  • Pair with YAML to ENV (the reverse direction, if you need one) to confirm nothing is lost in a specific round trip.

References

Frequently Asked Questions