Skip to content
AZ Tools

.env File Parser

Parse a .env / dotenv file with full support for single-quoted, double-quoted, multi-line, and inline-comment values.

.env file contents
Parsed entries (10 entries)
KeyValueInline comment
DATABASE_URL
postgres://user:pass@localhost:5432/mydb
DB_POOL_SIZE
10
APP_NAME
My App
APP_VERSION
1.0.0
APP_DEBUG
true
OAUTH_PRIVATE_KEY
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAxYz...
-----END RSA PRIVATE KEY-----
ROOT_DIR
/opt/app
LOG_DIR
${ROOT_DIR}/logs
EMPTY
∅
PORT
3000
default port
Export as:
Output
{
  "DATABASE_URL": "postgres://user:pass@localhost:5432/mydb",
  "DB_POOL_SIZE": "10",
  "APP_NAME": "My App",
  "APP_VERSION": "1.0.0",
  "APP_DEBUG": "true",
  "OAUTH_PRIVATE_KEY": "-----BEGIN RSA PRIVATE KEY-----\nMIIEowIBAAKCAQEAxYz...\n-----END RSA PRIVATE KEY-----",
  "ROOT_DIR": "/opt/app",
  "LOG_DIR": "${ROOT_DIR}/logs",
  "EMPTY": "",
  "PORT": "3000"
}

Variable expansion (${VAR}) is preserved literally — not resolved. Add a runtime expander if needed.

How to use

  1. Paste your .env file (or load the sample to see all supported syntax).
  2. Review the parsed key/value/comment table.
  3. Pick an export format and copy. Multi-line values are preserved (YAML uses |, Docker uses JSON-escaped string).

About this tool

Show

A parser for .env files that handles the cases real files actually contain: single and double quotes, values spanning several lines such as an RSA private key, a # comment trailing a value, an export prefix left over from a shell script, and keys with nothing after the equals sign. Once parsed, the table shows every key with its value and any trailing comment, and the result exports as JSON for a test fixture, YAML for a Helm chart, export lines for a shell, ENV directives for a Dockerfile, or TOML blocks for a Netlify environment context.

Quoting is the part worth getting right, because the two kinds of quote do different things. Inside double quotes, escape sequences resolve: \n becomes a real newline, \t a tab, \" a literal quote. Inside single quotes nothing resolves and the value is taken exactly as written, which is what you want for a password containing a backslash. Unquoted values are trimmed, and a # after them starts a comment — so a value with a hash character in it needs quotes, or half of it disappears.

${OTHER_VAR} references are deliberately left as written rather than substituted. Whether they expand at all depends entirely on what reads the file: Node's dotenv does it, Docker Compose does it in some positions, and a plain source .env in a shell expands them as shell variables along with anything else that looks like shell syntax. Substituting here would produce a file that is correct for one of those and silently wrong for the others.

Which brings up the thing .env shares with INI: there is no specification. Node, Python, Ruby, Docker Compose and source all disagree on details — whether quotes are stripped, whether export is tolerated, whether multi-line values exist at all. A file that works under one is not guaranteed to work under the next, so test the export you take from here in the environment that will actually read it. The parsing happens entirely in your browser, which is the relevant property for a file that is, by definition, a pile of secrets.

Frequently asked questions

What's the difference between single and double quotes?

Inside double quotes, escape sequences like \n, \t, \" are interpreted. Inside single quotes, they're literal — so FOO='line1\nline2' keeps the backslash-n. This matches the standard dotenv behavior used by dotenv (npm) and python-dotenv.

Does this expand ${VAR} references?

No — variable expansion is dotenv-implementation-specific and we want the parser output to faithfully represent the file as written. Use a tool like dotenv-expand after import if you need it.

Is the data sent anywhere?

No. Parsing happens entirely in your browser. The .env file content never leaves your device.

Why does the same file behave differently in Docker, a shell and my framework?

Because dotenv is a convention rather than a specification, and each implementation made its own choices about quoting, escapes, multi-line values, inline comments and whether a later line overrides an earlier one. Docker's env-file in particular does not do quote processing the way a library does. Keep values simple and quote deliberately when a file has to be read by more than one thing.

How should a value containing a newline or a quote be written?

Put it in double quotes, where an escape sequence is interpreted, and keep single quotes for values that must survive literally — a password containing a backslash is safer single-quoted. Long keys with real line breaks are the recurring problem: many readers accept a quoted multi-line value, several do not, and encoding the key as base64 on one line avoids the question entirely.

Related tools