What this does
Paste a .env file and get back a flat YAML mapping — one key per line, ready to paste into a Kubernetes ConfigMap's data:, a GitHub Actions env: block, or anywhere else that wants key/value config as YAML. Parsing uses the same rules the real dotenv npm package does (shared with .env Validator), so the values that come out are the values your application would actually receive — including the gotchas, like an unquoted # silently truncating a value.
Every key and value is emitted as an explicitly double-quoted YAML string, never a bare plain scalar. This matters more than it sounds: .env values are always strings, but an unquoted PORT: 3000 or FLAG: yes in YAML gets read back as a number or boolean by most YAML parsers — yes/no/on/off especially, which several real-world YAML consumers (Docker Compose among them) still treat as booleans. Quoting every value sidesteps that ambiguity entirely rather than relying on a "quote only if needed" heuristic that's different for every YAML schema.
Comments and blank lines carry over into the output in their original positions. A duplicate key becomes a comment noting which line's value actually won (dotenv keeps only the last one), and a line that fails to parse becomes a # skipped — ... comment rather than silently vanishing or breaking the output.
What it doesn't do
This produces a flat mapping only — it doesn't nest output under a parent key (like Docker Compose's environment:) or convert to a list-of-objects shape (like a Kubernetes container's env: array). Both are one paste away from this output, just wrapped differently depending on where you're using it. It also doesn't support dotenv's obscure KEY: value colon-separator syntax, same as the Validator — see that tool for the full list of parsing rules this shares.
FAQ
Why quote yes/no instead of leaving them as YAML booleans?
Because they were never booleans — FEATURE_FLAG=yes in a .env file is the three-character string "yes", and every consumer of that file reads it as a string. Converting it to an unquoted YAML boolean would silently change its type, which is exactly the kind of bug a format conversion shouldn't introduce.
What happens to a line the parser can't make sense of?
It's commented out in the output with a note explaining it was skipped, rather than omitted with no trace or allowed to produce invalid YAML. Check .env Validator for the full explanation of what's wrong with any flagged line.