How to Validate Environment Variables and Clean a .env File in Your Browser

A .env file looks harmless until a deploy fails and the error message is something vague like "command not found" or "bad variable name." The cause is almost always a key the shell refuses to export. Spaces, hyphens, a leading digit, a stray $ in a value — any of these breaks the file, and most of the time you only find out after the pipeline goes red.

The Environment Variable List Validator checks a pasted list or an uploaded text file one row at a time, flags every entry that fails, and writes the reason next to it. The parsing, validation, and export all run in the browser, so a .env with real secrets never leaves the tab.

The naming rule a shell actually enforces

A POSIX-safe environment variable name must start with a letter or an underscore and contain only letters, digits, and underscores — written as the pattern [A-Za-z_][A-Za-z0-9_]*. That single rule rejects more keys than people expect:

• 1API — starts with a digit, so it's illegal. The first character can be a letter or _, never a number.
• MY-KEY — a hyphen isn't in the allowed set. Shells read - as part of an expression, not a name.
• MY KEY — a space splits the assignment into two tokens, so the shell can't export it at all.

Each of those three is a name your shell will simply refuse. The validator checks each key against this rule and marks the bad ones rather than letting them slide into a deploy. Its FAQ states the check directly: a key that isn't of the form [A-Z_][A-Z0-9_]*, a duplicate KEY= that a later line overrides, or a value carrying an unescaped $. Those are the three failure classes it reports.

What this tool checks, exactly

I want to be precise about scope, because format validation gets oversold. This tool does three things, all per the manifest:

1. Key shape. Every key is tested against the env var naming rule. A name with a hyphen, a space, a leading digit, or any other disallowed character gets flagged with its reason.
2. Duplicate keys. If the same KEY= appears more than once, the later assignment silently wins in a real shell. The validator surfaces the duplicate so you decide which one to keep instead of guessing.
3. Unescaped $ in values. A value containing a bare $ can trigger unintended shell expansion. That row is flagged so you can quote or escape it.

What it does not do: it never confirms that the account, domain, or resource behind a variable actually exists. A perfectly formatted DATABASE_URL can still point at nothing. Format validation is not existence validation — keep that line clear in your head, and it's listed in the tool's own common mistakes for the same reason.

A worked example

Say you paste this list, copied out of a teammate's config note:

DATABASE_URL=postgres://localhost/app
1API_KEY=sk_live_abc
MY-SERVICE=on
LOG LEVEL=debug
API_KEY=first
API_KEY=second
PASSWORD=p$ssw0rd

The validator walks it row by row and returns a report with a reason beside every line. As CSV output, you get something like:

key,value,line,valid,reason
DATABASE_URL,postgres://localhost/app,1,true,OK
1API_KEY,sk_live_abc,2,false,key must match [A-Za-z_][A-Za-z0-9_]*
MY-SERVICE,on,3,false,key must match [A-Za-z_][A-Za-z0-9_]*
LOG LEVEL,debug,4,false,key must match [A-Za-z_][A-Za-z0-9_]*
API_KEY,first,5,false,duplicate key later overridden
API_KEY,second,6,true,OK
PASSWORD,p$ssw0rd,7,false,unescaped $ in value

Three illegal names (1API_KEY starts with a digit, MY-SERVICE has a hyphen, LOG LEVEL has a space), one duplicate that an earlier line loses to, and one value with an unescaped $. The valid rows stay right next to the flagged ones, so you fix the source file instead of hunting through it blind. That side-by-side layout is deliberate — you're meant to edit the real config, not just read a pass/fail count.

Cleaning the list and exporting the artifact

Once you can see the failures, the tool gives you the cleanup levers. You can keep unique rows only, or preserve the invalid rows for review when you need the audit trail. You can sort the normalized output so two configs diff cleanly. And you can switch the output between CSV, JSON, Markdown, SQL IN, a TypeScript union, and plain lines, then download the exact format your next step wants.

One detail worth flagging: text copied from a web page or a chat often carries hidden whitespace, so normalize before you deduplicate or import — otherwise two "identical" keys won't collapse. For sensitive profiles such as cards and JWTs, the tool masks values in the output while still reporting useful validation signals, so you can share a report without leaking the secret itself.

Where it fits in a real workflow

I keep this open as the last step before I commit a .env.example or hand a config off to a teammate. The pattern I trust: paste the file, scan the flagged rows, fix the names at the source, then export the clean CSV with line numbers so there's a record of what changed. It has caught a LOG LEVEL typo for me more than once — the kind of thing that passes a casual eyeball and then dies in CI.

If your job is more about pulling keys out of messy text than validating them, the Environment Variable Extractor is the better starting point, and you can chain its output back into the validator. For a sized-up .env, the tool is built for a few megabytes — a single config, a ConfigMap export, a pasted CI variable list. Split a giant aggregated config locally first, then run each piece through.

The whole point is to move the failure earlier. A bad variable name costs you a red pipeline at deploy time; the same name costs you ten seconds in a validator that runs entirely in your browser. That's a trade worth making every time.

---

Made by Toolora · Updated 2026-06-13