.env Parser & Validator

Paste a .env file — or drop it onto the box — and get it back parsed, checked and explained: every key in a table with its value masked, every problem listed with its line number. Duplicated keys, invalid names, lines that are not assignments at all, empty values that silently override defaults. It runs entirely in your browser and the file is never uploaded, because a production .env is a bundle of secrets and should be treated like one.

What gets checked, and why

The .env format is a convention, not a standard, which is why files rot quietly. Every loader agrees on KEY=VALUE and disagrees about everything else: whether export prefixes are stripped, whether quotes are honoured, whether an inline comment ends a value, and — most dangerously — which of two definitions of the same key wins. This validator applies the common-denominator rules and reports the places where loaders diverge: a key defined twice with both line numbers, a name no shell would accept, a quote that opens and never closes, a line with no equals sign at all. Empty values get flagged rather than failed, because KEY= is legal — but it overrides any application default with an empty string, which is the single most common reason a service works on one machine and not another.

The privacy design is the feature. A production .env concentrates database passwords, API keys and session secrets into one small file, and the natural debugging move — paste it somewhere and ask for help — is also the leak. AI chats, issue trackers and team channels all retain copies, often searchable, often forever. So this tool follows the same rule as the log parser and the certificate generator: the sensitive input never leaves the browser, values are masked on screen, and the only exports are files you deliberately download. The companion article, env files are where secrets go to leak, covers the hygiene around the file itself — what belongs in it, what does not, and what to do when one escapes.

Frequently asked questions

Is it safe to paste a production .env here?

Yes — that is the point of this tool. The parsing runs entirely in your browser: there is no upload, no server round-trip, and nothing you paste is transmitted or stored anywhere. Values are masked on screen by default, so a screen-share or a screenshot does not leak them either. The same cannot be said for pasting a .env into an AI chat, a ticket or a team message, all of which keep copies — the article on env files and leaking secrets explains the safer habits.

Why does a duplicate key matter if the last one wins?

Because the human editing the file does not know which one wins. They change the value on line 4, redeploy, and watch nothing happen — the loader quietly used line 41. Worse, some frameworks take the first definition and some the last, so the same file behaves differently across a stack. One key, one line, one value: the validator lists every duplicate with both line numbers so the dead line can be deleted.

My app reads a variable that is not in the .env. How do I find those?

Paste your code or config into the usage box. The parser extracts every referenced name — process.env.X, process.env[’X’], import.meta.env.X, ${X} and $X — and reports both directions: names the code references that the file never defines (these become undefined at runtime, usually at the worst moment), and keys the file defines that nothing references (dead config that still holds live secrets surprisingly often).

What counts as an invalid key?

Anything that is not a letter or underscore followed by letters, digits and underscores. Keys starting with a digit, containing dashes or dots, or carrying stray spaces are dropped or mangled by many loaders and shells — a file that sources cleanly in bash can fail in a Node loader for exactly this reason. The validator flags them with the line number; the entries table still shows the row so you can see what would be lost.

Do the exports contain the real values?

Yes. The JSON and YAML downloads and the copied JSON are the real configuration — masking is a display protection, not a redaction of your own data. Treat exported files exactly like the .env itself: never commit them to a public repository, never attach them to a ticket. If you need a shareable, safe version, share the masked screenshot or the key list instead.