.env File Parser
Inspect Node-style dotenv assignments in source order, understand quoting and comments, spot duplicate variables, and mask likely credentials before copying the visible result.
Paste the file text itself. Nothing is sourced or executed.
0 lines
Parsed Environment Data
Source order is shown separately from the effective later-value-wins view.
Assignments, duplicate warnings, effective values, and parser diagnostics will appear here.
Treat real .env files as secret material
.env files often contain database passwords, cloud keys, API tokens, signing secrets, and connection strings. Parsing stays in your browser and no dotenv-parsing API receives the pasted text, but the input still exists on your screen and masking applies only to the visible result. Avoid screenshots, screen sharing, or copying unmasked credentials. Site-wide analytics or advertising scripts, if enabled, are separate from this parsing operation.
The Useful Question Is: What Value Will the Process Receive?
A dotenv file looks like a simple list of NAME=value assignments, but small formatting choices can change the value a program receives. Quotes can preserve spaces and # characters, quoted values can span lines, comments can remove the rest of an unquoted line, and the same variable can be assigned more than once.
Keeping the original assignment order visible prevents a duplicate near the bottom of the file from disappearing silently behind an object conversion. The later-value-wins view is shown separately because Node's util.parseEnv() also resolves repeated names to the later value.
Four Lines That Look Similar but Parse Differently
NAME=Sneha # comment NAME="Sneha # Pune" EMPTY= FEATURE=true
The first value is Sneha; the unquoted # begins a comment.
The second value includes # Pune because the hash is inside quotes.
EMPTY= is a real assignment whose value is the empty string.
true remains text. Node.js dotenv parsing does not turn it into a JavaScript boolean.
Everything Is a String
Values such as 0, false, null, or {"mode":"dev"} may look like numbers, booleans, null, or JSON, but a dotenv parser supplies them as text. Your application is responsible for converting them to the type it expects.
This is a common source of configuration bugs. For example, the string "false" is truthy in ordinary JavaScript if an application checks it without explicitly parsing the intended boolean meaning.
Duplicate Variables Deserve to Stay Visible
Configuration files are frequently edited by several people, generated by scripts, or assembled during deployment. A variable can be defined near the top and then accidentally redefined much later. A normal JSON object cannot represent both assignments at once.
The source-order section preserves every occurrence and reports the previous line. The effective view deliberately uses the later assignment, making it easier to understand why a value you changed earlier in the file does not appear to take effect.
Quoting Protects Content From Comment and Whitespace Rules
Leading and trailing whitespace around an unquoted value is ignored in the Node.js dotenv model. Inside quotes it belongs to the value. A # outside quotes starts a comment; inside quotes it is ordinary text. Quoted values can also continue across multiple physical lines.
Single, double, and backtick-quoted entries are labeled separately. Double-quoted \n becomes a newline in Node's parser; single and backtick quoting keep that sequence literal. None of these forms turns the file into shell syntax.
There Is No Universal .env Standard
“Dotenv” is a convention used by many ecosystems, not one universal cross-platform file format. Node.js documents its own grammar. Docker Compose has its own env-file/interpolation behavior. Popular dotenv libraries and frameworks can differ on expansion, escaping, comments, delimiters, override precedence, and multiline syntax.
The parser profile is therefore stated explicitly instead of implying that one dotenv result predicts every runtime. Node.js itself notes that there is no formal cross-ecosystem dotenv specification in its environment-variable documentation.
Why $VARIABLE Is Left Alone
Variable expansion is not part of the documented Node.js dotenv grammar used here. A value such as API_URL=$BASE_URL/api is therefore preserved as text. Some libraries add expansion as a separate feature, and Docker Compose performs its own interpolation in Compose-related workflows. Expanding variables in a generic parser would require assumptions about environment precedence and could reveal secret values unexpectedly.
Secret Masking Is a Sharing Aid, Not Secret Detection
The mask looks only at variable names that resemble credentials. It can hide API_TOKEN while completely missing a secret stored under an innocent name such as VALUE. It can also mask a harmless variable whose name contains SECRET or TOKEN.
Masking reduces accidental exposure in copied output; it is not a security guarantee. Placeholder credentials remain safer whenever real values are unnecessary.
Follow the Variable Into Its Runtime
Parsing explains what the file text means. The next question is which source wins when the process starts: the parent environment, one or more --env-file inputs, a framework loader, or deployment configuration. Node documents its own CLI precedence in the --env-file option.