Skip to content
Advertisement

.env File Converter

Parse a dotenv file the way real readers do — quoting, escapes, comments — and retype it as JSON, YAML, docker flags, Compose, a Secret or a ConfigMap.

Converter Config

14 lines

259 chars

8 variables — parsed in this browser. Nothing here is uploaded, which is the only reason it is reasonable to paste a production .env into a web page.

Settings

How .env File Converter works

There is no specification for the .env format. What exists is a family of implementations that grew out of one Ruby library and now includes readers in every language, plus Docker’s --env-file and Compose’s own parser. They agree on the shape — a name, an equals sign, a value, one per line — and diverge on everything after that: whether quotes are stripped, which escapes are honoured, where a comment can start, and whether a reference to another variable is expanded at all. A file that loads correctly under one reader can load differently under the next without either being wrong.

Quoting is where the divergence bites hardest, and it carries real meaning rather than being decorative. A single-quoted value is literal: a backslash-n inside it stays two characters, and a dollar sign stays a dollar sign. A double-quoted value honours escapes, so backslash-n becomes an actual newline, and it may run across several lines, which is how a PEM key or a JSON blob ends up inside an environment file. An unquoted value ends at the line break, with any trailing comment removed — provided the hash that starts the comment has whitespace in front of it. Without that space, most readers keep the hash as part of the value, which is why a hex colour written as a bare value survives and a hash used to annotate one does not.

Interpolation is the other fault line. Some readers expand a reference to a variable defined earlier in the same file, some expand against the surrounding process environment, some do both, and Docker’s --env-file does neither — it passes the literal text through. Because expansion resolves against what came before, order matters in a format that otherwise looks order-independent, and a reference to a name defined further down silently becomes empty.

Retyping the same pairs as a Kubernetes Secret introduces the one point worth stating plainly: the base64 in a Secret is an encoding, not a protection. It exists so binary values can travel through YAML, and it is reversed by a single command with no key involved. A Secret keeps values out of a pod spec and out of most logs; it does not keep them from anyone able to read the namespace, and a Secret manifest committed to a repository is a plaintext credential with one extra step in front of it.

Reference

  • KEY=value · export KEY=value · KEY= (empty)
  • 'literal' — no escapes, no expansion · "escaped" — \n \t \" \\ honoured, may span lines
  • value # comment — a hash needs whitespace before it to start a comment
  • ${VAR} · $VAR · ${VAR:-default} — resolved against variables set earlier
  • Shell-safe name: [A-Za-z_][A-Za-z0-9_]*
  • Secret or ConfigMap key: [-._A-Za-z0-9]+

How to use this converter

  1. Paste the file

    Comments, blank lines, export prefixes and multi-line quoted values are all handled; nothing needs stripping first.

  2. Read what the parser flagged

    Duplicate names, names no shell can export, and hashes ambiguous enough that readers disagree about them are reported rather than resolved silently.

  3. Choose the shape you need

    JSON, a YAML map, docker run flags, a Compose environment block, a Secret or a ConfigMap. The same pairs, retyped for wherever they are going next.

  4. Decide about expansion before you copy

    The toggle is off by default because the destination may do its own expansion, and expanding twice produces a value nobody wrote.

Worked examples

Quotes changing what an escape means

Given
A="line\\nbreak" beside B='line\\nbreak'
Result
A holds a newline; B holds a backslash and an n

The single most common surprise in the format. Single quotes are the way to keep a value exactly as typed.

A hash that is not a comment

Given
COLOR=#ff0000
Result
#ff0000

No whitespace before the hash, so it stays in the value under the common readers. Written as COLOR= #ff0000 the value would be empty instead.

A reference resolved in file order

Given
DB_HOST=postgres then DATABASE_URL=postgres://${DB_HOST}:5432
Result
postgres://postgres:5432

Reversing the two lines yields postgres://:5432 with no error, because expansion only ever looks backwards.

The same variable as a Secret

Given
API_TOKEN=s3cr3t
Result
data: { API_TOKEN: czNjcjN0 }

Eight characters of base64 that decode back to the token instantly. Encoding, not encryption.

When to use it

  • Moving a local development file into a deployment manifest without retyping thirty variables by hand.
  • Producing the docker run command that reproduces what Compose does, for a one-off debugging container.
  • Finding the duplicate assignment that explains why a variable holds a value nothing in the file appears to set.
  • Checking whether a multi-line certificate or private key survived being pasted into an environment file.
  • Converting a Secret back into a .env file for local work, then confirming the values round-trip unchanged.

Things to watch out for

  • A duplicate name is not an error anywhere: the last assignment wins, in this parser and in every reader. It is reported because a file that sets one variable twice usually means someone edited past the first one.
  • Names starting with a digit or containing a dash are accepted by some loaders and unusable from a shell, which cannot export them. They are flagged rather than rejected.
  • A Secret key and a shell variable name allow different characters. A name with a dot works as a Secret key and not as an exported variable; a name with a dollar sign works as neither.
  • ConfigMap uses a plain data field for string values. The stringData field belongs to Secret, where it is a write-only convenience that the API server converts to base64 on the way in.
  • Everything in a .env file is a string. Values that a YAML 1.1 reader would turn into a boolean or a base-60 number are quoted in the YAML outputs so that they stay strings wherever they land.

Frequently asked questions

Do I need quotes around values in a .env file?

Only when the value contains spaces, a hash, a newline or characters you want protected from escape processing. Quoting also removes any ambiguity about where the value ends, which is worth it for anything a reader might otherwise have to guess about.

What is the difference between single and double quotes here?

Single quotes are literal — nothing inside them is interpreted, including backslash escapes and variable references. Double quotes process escapes such as \n and \t, and are the only form that lets a value span more than one line.

Is a Kubernetes Secret encrypted?

No. The values are base64-encoded so that binary data can travel through YAML, and decoding needs no key at all. Encryption at rest is a separate cluster setting, and it does nothing for a manifest sitting in a repository.

Why is my variable empty even though the file sets it?

The usual causes are a later duplicate assignment overwriting the first, a hash preceded by a space turning the rest of the line into a comment, or an expanded reference to a name that is defined further down the file.

Does the export prefix do anything?

Not to a dotenv reader, which accepts and ignores it. It exists so the same file can be sourced directly by a shell, where export is what actually places the variable into the environment of child processes.

Can a value contain a newline?

Yes, either as a \n escape inside double quotes or as a real line break inside a quoted value that spans lines. This is how certificates and private keys are normally carried, though a mounted file is a better home for them.

Related DevOps tools

All devops tools