.env Syntax Validator

Every team that has ever shipped a Node, Python, or Rails app has, at some point, spent twenty minutes debugging a service that “just wouldn’t start” — only to discover the real problem was a stray space, a missing quote, or a .env file with two DATABASE_URL lines where the second one silently overrode the first. A .env file looks like the simplest file in your repo, but its syntax has more edge cases than most developers realize, and because most languages’ dotenv parsers fail silently rather than throwing an error, a broken line doesn’t crash your app — it just quietly gives you the wrong value, or no value at all, and you find out in production.

This tool checks a pasted or dropped .env file for exactly the mistakes that cause that kind of quiet failure: lines with no = sign, duplicate keys (where most parsers keep the first occurrence and silently drop every one after it), values with unquoted spaces that get truncated by some parsers, an accidental space after = that becomes part of the value, and keys that don’t follow the conventional UPPER_SNAKE_CASE most tooling expects. It also flags a byte-order mark (BOM) at the start of the file and mixed Windows/Unix line endings — both are invisible in most text editors and both have broken real deployments.

Because a .env file is exactly the kind of file you don’t want landing on a third-party server, everything here runs client-side: nothing you paste or drop is ever uploaded, logged, or saved — not even to this browser’s local storage, since the whole point of the file is that it might contain real credentials. Values that look like keys, secrets, tokens, or passwords are masked by default, with a per-value reveal toggle so you’re not staring at plaintext API keys while screen-sharing a debugging session.

Beyond catching mistakes, the tool also produces things you’ll actually use afterward. It can diff your .env against a second file — typically .env.example — and show you exactly which keys exist in one but not the other, which is the fastest way to catch “works on my machine” bugs caused by a teammate’s environment drifting from what the app actually expects. It can generate a fresh .env.example from a real .env, stripping every value but keeping the keys and structure, so new contributors always know what variables to set without you maintaining that file by hand. And it can export your variables straight to JSON, YAML, shell export lines, or a TypeScript interface, so you’re not retyping the same list of keys into four different formats.

One thing worth remembering on the config side of this: a .env file should never be committed to version control in the first place, and if yours isn’t already excluded, our .gitignore generator can build a proper ignore file for your stack in a few clicks. If you’re exporting to JSON and want to pretty-print or further validate the result, our JSON formatter handles that directly. And if you need a deeper, line-by-line comparison than the key-presence diff here — say, comparing two full config files word for word — our diff checker is built for exactly that.

Common questions:

Does this replace a real dotenv parser?

No — it’s a heuristic checker built to match common conventions (dotenv-style escaping, export KEY=value support, comments with #), not a spec implementation of any one library, so it won’t catch every parser-specific quirk.

Is it safe to paste production secrets in?

Yes — the check happens entirely in your browser’s memory and nothing is transmitted or stored, but as with any tool, if your organization’s policy requires it, redacting real values before pasting is always the more cautious choice.