.env Portability Preflight
Paste the contents of a .env file and see exactly which values would be read differently — or break outright — across Node's dotenv package, Docker/Docker Compose, and a POSIX shell sourcing the same file directly. Everything runs entirely in your browser: nothing you paste here is ever uploaded, logged or sent anywhere, which matters because a real .env file usually contains secrets.
Processed locally in your browser. Your file is never uploaded.
How to use this calculator
- Paste your .env file's contents (or a representative excerpt) — analysis happens entirely in your browser, so real secret values never leave this page.
- Select "Check .env file".
- Review each flagged line: what's ambiguous or risky, and which of dotenv / Docker Compose / a POSIX shell disagree about it.
- Apply the suggested rewrite where one is offered — a few cases (an unterminated quote, a duplicate key, an interpolation reference, an invalid key name) are deliberately left for you to resolve by hand, because guessing wrong would be worse than not guessing.
Assumptions
- Expects one KEY=value per line, `#`-prefixed comment lines, and blank lines — the conventional .env shape used by dotenv, Docker Compose's env_file, and POSIX shell sourcing alike.
- A value is only treated as "quoted" when it starts and ends with a matching pair of double or single quotes — a stray quote elsewhere in the value is exactly what the unterminated-quote check is for.
- Never assumes what a duplicate key, an interpolation reference, or an invalid key name was supposed to mean — those are reported as issues, not silently resolved.
Methodology
Each line is parsed into a key, its raw value, and whether the value is quoted, then checked against the specific, well-documented ways dotenv, Docker/Docker Compose and a POSIX shell disagree on .env syntax: unquoted spaces and unquoted `#` (parsed differently or truncated), an `export` prefix (accepted, stripped or rejected depending on the parser), unterminated quoting (inconsistent multi-line behavior), `$VAR`/`${VAR}` interpolation (expanded by shell/Compose, left literal by dotenv unless dotenv-expand is also used), duplicate keys (silently overridden by the last occurrence), trailing whitespace on an unquoted value (kept by dotenv, stripped by a shell export), and key names that aren't valid POSIX shell identifiers. A rewrite is offered only for the genuinely safe cases — quoting a value, trimming trailing whitespace, or removing an export prefix — never for anything that would require guessing at intent.
Worked example
A value referencing another variable
Inputs: API_URL=${BASE_URL}/api
Result: dotenv does NOT expand "${BASE_URL}" by default — the literal string ends up in API_URL unless the separate dotenv-expand package is also used — but a POSIX shell sourcing the file, and Docker Compose, DO expand it. Flagged as a warning; no rewrite is offered because whether expansion was intended can't be inferred from the file alone.
An export prefix
Inputs: export APP_NAME=My Example App
Result: Valid POSIX shell syntax, but dotenv and Docker Compose disagree on how to handle the "export " prefix — some reject it, some fold it into the key name. Flagged as a warning and safely rewritten to drop the prefix, since dotenv (the most common consumer of these files) expects the plain form. The unquoted space in the value is flagged separately as its own, higher-severity issue.
A duplicate key
Inputs: TIMEOUT=30 TIMEOUT=60
Result: Most parsers, including dotenv, silently keep only the last occurrence — TIMEOUT=30 is quietly discarded. Flagged as a warning on the second occurrence, referencing the line it overrides.
Practical guidance
- Quote any value that contains a space or a "#" character, even though dotenv alone would accept it unquoted — quoting is what makes the file behave the same way if it's ever sourced directly or read by Docker Compose.
- Avoid $VAR / ${VAR} references in .env files unless you've confirmed every consumer of that file expands them the same way — this is one of the most common real-world .env portability bugs.
- Don't rely on "export" prefixes for compatibility with dotenv-based tooling — write the plain KEY=value form, and use a shell wrapper script if you also need to source the file directly.
Common mistakes
- Assuming a value that "works" when the app starts is portable — an unquoted space, an unexpanded interpolation reference, or a silently-overridden duplicate key can all load successfully while still holding the wrong value.
- Treating .env key names as free-form labels — a key with a hyphen or a leading digit is accepted by lenient parsers like dotenv but will break the moment the same file is sourced by a real shell.
FAQs
Is it actually safe to paste real secret values into this tool?
The analysis runs entirely in your browser — nothing you paste is uploaded, logged or transmitted anywhere, and this page adds no analytics or telemetry of its own. That said, treat any tool the same way: if you're not comfortable pasting a value, use a placeholder with the same shape (same length, same special characters) instead — the checks here only look at syntax, not the value's actual meaning.
Why is an unquoted space an error but a trailing space only info?
An internal unquoted space actively breaks the assignment in a POSIX shell or a strict Docker Compose parser — it's a real functional break. Trailing whitespace after an otherwise normal value just risks an unexpected extra character in dotenv's reading of it; annoying, but rarely fatal, and safe to trim automatically.
Why won't the tool fix a duplicate key or an invalid key name for me?
Both require deciding what you actually meant: which of two duplicate values is the real one, or what the corrected key name should be. Guessing wrong and silently changing your file would be worse than pointing out the problem and letting you decide.