Skip to content

ENV Parser

Convert a .env file to JSON, YAML, shell exports, Docker flags or tfvars, and catch duplicate keys and quoting mistakes before they reach a container.

.env

JSON

Paste a .env file to convert it.

Parsing and conversion run in your browser. Database URLs, API keys and passwords in the file are never uploaded, stored or logged — masking only affects what is shown on screen.

About the ENV Parser

Paste a .env file and convert it to JSON, YAML, shell exports, docker run flags, a Compose environment block or Terraform tfvars — while checking it for the mistakes that make a config silently wrong. Everything runs in your browser, which matters here more than for most tools: a .env file is usually the single most sensitive file in a repository.

There is no specification for this format. It is whatever dotenv happened to implement, and the loaders disagree at the edges, which is exactly where the bugs live. This parser follows the behaviour the mainstream implementations share: `#` starts a comment only when it begins a token, so a `#` inside a password survives; single quotes are literal while double quotes expand `\n`; unquoted values are trimmed and quoted ones are not; and a quoted value may run across lines.

The conversions are quoting-aware rather than string concatenation. Shell output uses POSIX single quotes, the one style with no escape sequences to get wrong, so a secret containing `$` or a backtick cannot be expanded by the shell it is sourced into. YAML output quotes any value that YAML would otherwise retype — `true`, `no`, `123`, `~` — because a port number silently becoming an integer is a genuinely common outage.

  • Six output formats: JSON, YAML, shell exports, docker run flags, Compose and tfvars
  • Duplicate keys, missing `=`, unterminated quotes and non-portable names all reported with line numbers
  • Comment handling that keeps a `#` when it is part of a password
  • Shell output single-quoted, so `$`, backticks and spaces cannot be expanded
  • YAML output quoted wherever a bare value would change type
  • Secret-looking keys masked in the on-screen table

How to use it

  1. Paste the contents of your .env file into the left pane.
  2. Pick an output format — JSON for a config loader, shell for something you will source, Compose or docker for a container.
  3. Read the issues panel. Duplicate keys and unterminated quotes are the two that most often explain a variable that is not what you expected.
  4. Check the variables table to confirm each value parsed the way you meant, especially anything containing a `#` or leading whitespace.
  5. Copy the output. Leave masking on if anyone can see your screen.

Real-world use cases

Backend developers

Convert a local .env into the JSON your config loader expects, or catch a duplicate key silently shadowing the database URL you thought you set.

DevOps & platform engineers

Turn a .env file into docker run flags or a Compose environment block when wiring up a container, without hand-translating each line and risking a quoting mistake.

Infrastructure & Terraform engineers

Convert application secrets into a tfvars file for a module that provisions the same environment variables as infrastructure, keeping one source of truth instead of two hand-maintained lists.

New team members onboarding

Paste a teammate's .env.example to see it laid out as a table with masked secrets, rather than reading raw KEY=value lines to work out what each one is for.

Security-conscious teams

Check a .env file for the mistakes that leak secrets sideways — an unescaped # truncating a password, or a value that will be silently overwritten by a duplicate key further down the file.

Examples

A file to JSON

Input
NODE_ENV=development
PORT=3000
DATABASE_URL=postgres://localhost/app_dev
Output
{
  "NODE_ENV": "development",
  "PORT": "3000",
  "DATABASE_URL": "postgres://localhost/app_dev"
}

Every value is a string, including PORT. That is not a simplification — environment variables are strings, and a loader that returns a number for one of them is lying to you.

A # that is part of the value

Input
PASSWORD=abc#123
TIMEOUT=30 # seconds
Output
{
  "PASSWORD": "abc#123",
  "TIMEOUT": "30"
}

The first # has no whitespace before it, so it is part of the password. The second does, so it starts a comment. Parsers that split on the first # truncate passwords.

Shell exports

Input
GREETING="hello world"
SHELL_TRAP=$HOME/`whoami`
Output
export GREETING='hello world'
export SHELL_TRAP='$HOME/`whoami`'

Single quotes mean the shell expands nothing. Double quotes here would run `whoami` and substitute $HOME the moment the file was sourced.

YAML, with types preserved

Input
DEBUG=true
PORT=3000
FEATURE_FLAG=no
Output
DEBUG: "true"
PORT: "3000"
FEATURE_FLAG: "no"

All three are quoted. Bare, YAML would read them as a boolean, an integer and — under YAML 1.1 rules, which many parsers still use — false.

Common errors

MessageCauseFix
Variable is empty at runtime but set in the fileUsually a duplicate key later in the file, or the value was truncated at an unescaped `#`.Check the issues panel — duplicates are reported with both line numbers, and the table shows exactly what each value parsed to.
Value has unexpected quotes around itThe quotes were escaped or doubled in the source, so they became part of the value rather than delimiting it.Quote once: KEY="value", not KEY=""value"". The character count in the table makes an extra quote obvious.
Spaces in a value are missingThe value was unquoted, and unquoted values are trimmed and end at the first comment marker.Wrap it in quotes. Quoted values preserve whitespace exactly, including leading and trailing spaces.
Port becomes a boolean or number after conversion to YAMLBare YAML scalars are typed. `no` becomes false under YAML 1.1, `3000` becomes an integer, `1.10` becomes 1.1.Quote them — this tool does so automatically for every value YAML would retype.
Sourcing the file runs a command or mangles a passwordThe value contained `$`, a backtick or a space and was written unquoted or double-quoted, so the shell expanded it.Use the shell output here, which single-quotes everything. Never `source` a raw .env containing untrusted values.
Variable works locally but not in Dockerdocker run does not process quotes the way a shell does, so quotes written in the file end up inside the value.Use the docker or compose output, which passes each value as one already-quoted argument.

Frequently asked questions

Is my .env file uploaded anywhere?

No — and this is the tool where that matters most. Parsing and conversion run entirely in your browser. Database URLs, API keys and passwords never leave the page, nothing is stored or logged, and you can confirm it by using the page with your network disconnected.

Why is every value a string?

Because environment variables genuinely are strings — that is all the operating system can hold. PORT=3000 is the three characters "3000", and any typing happens in your application when it reads the value. A converter that guessed types would be inventing information that is not in the file.

When do I need quotes in a .env file?

Whenever the value has leading or trailing whitespace you want kept, contains a `#` preceded by a space, or spans lines. Otherwise quotes are optional. Single quotes are literal; double quotes expand \n, \t and \", which is the only reason to prefer them.

What happens with a duplicate key?

Both entries are kept and shown, and a warning names the earlier line. Most loaders take the last value, but not all of them do — which is precisely why it is worth flagging rather than silently resolving.

Is the shell output safe to source?

Yes. It uses POSIX single quotes, inside which nothing is expanded — no variable substitution, no command substitution, no escape sequences. An embedded single quote is handled by closing, escaping and reopening the quote, which is the standard safe construction.

Why does the YAML output quote so much?

Because a bare YAML scalar is typed by its content. Left alone, `true`, `no`, `on`, `null`, `~`, `3000` and `0x1f` would all stop being strings, and under YAML 1.1 rules a value like `no` becomes boolean false. Quoting is applied only where leaving it bare would change the value.

Does masking make it safe to share my screen?

It hides values whose key looks like a credential — anything matching secret, password, token, api_key, private_key, credential or auth. It is a convenience, not a guarantee: a secret stored under an unusual name will not be caught, and the full value is still in the input pane.

Which output format should I use for Docker?

The Compose output for a docker-compose.yml environment block, or the docker output for docker run --env-file-style flags. Both pass each value as a single already-quoted argument, which avoids the mismatch between how a shell and how docker run interpret quotes in a raw .env file — the source of the classic 'works locally, breaks in the container' bug.

Last updated