.env File Parser
Parse a .env / dotenv file with full support for single-quoted, double-quoted, multi-line, and inline-comment values.
| Key | Value | Inline 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 |
{
"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
- Paste your
.envfile (or load the sample to see all supported syntax). - Review the parsed key/value/comment table.
- Pick an export format and copy. Multi-line values are preserved (YAML uses
|, Docker uses JSON-escaped string).
About this tool
ShowHide
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
JSON ↔ YAML Converter
Convert JSON to YAML or YAML to JSON — pick the indent and copy the result.
Convert
Markdown Frontmatter Parser
Paste or drop a Markdown file, extract the YAML / TOML / JSON frontmatter into a JSON object, and see the body separately with word and char counts.
File
Java .properties Parser
Parse a .properties file exactly as java.util.Properties.load does — separators, escapes, continuations — and see every line that will surprise you.
Developer
BSON Decoder & Extended JSON Viewer
Decode a MongoDB BSON file in your browser: every element type with its type byte, exact int64 and decimal128, and canonical or relaxed Extended JSON.
Developer
CSV ↔ JSON Converter
Convert CSV to JSON and JSON back to CSV, with a delimiter option.
File
EML File Viewer
Drop an .eml file and read the parsed message — key headers, plain-text and HTML body parts, and a list of attachments — all in the browser.
File