.env Validator — parser, secret scan, required-key check, prod/staging/dev diff

Real-world use cases

• Catch a duplicated key before it silently overrides in production

  You added `STRIPE_KEY=sk_test_…` at the top of `.env`, then a week later added `STRIPE_KEY=sk_live_…` at the bottom while merging a PR. Node `dotenv` keeps the LAST one; your local tests pass with the test key but staging boots with live. Paste the file here, the "Duplicate keys" panel calls out STRIPE_KEY appearing on lines 4 and 41 with both values shown side-by-side. Delete one, ship.

• Verify a new microservice has every required env before docker-compose up

  You spun up a new Rust service that needs `DATABASE_URL`, `REDIS_URL`, `JWT_SECRET`, `SENTRY_DSN`. The README's "config" section lists them. Paste those four lines into the schema field as `KEY=required`, paste your `.env` on the left. The "Schema" tab shows green for each present non-empty key and red for whatever you forgot — usually `SENTRY_DSN`, every time. Saves the 30-second container boot + crash loop.

• Spot a leaked AWS access key before pushing

  Someone on the team left `AWS_ACCESS_KEY_ID=AKIAIOSFODNN7…` in `.env.example` because "it's just an example". The secret scanner highlights it as AWS-shaped, your CI gitleaks step would have caught it eventually but only after a 4-minute run. Catch it in 200ms here, rotate the key (it's already public — assume burned), update `.env.example` with `AWS_ACCESS_KEY_ID=AKIA_REPLACE_ME`.

• Diff staging vs production env to confirm a single intentional change

  You're rolling out a feature that needs a new env var `FEATURE_NEWPAY_ENABLED`. You think production differs from staging in only that variable + the obvious DB URL / region. Paste both files into the "Diff" tab, the table shows: 47 keys identical, 3 keys differ (DB_URL, AWS_REGION, FEATURE_NEWPAY_ENABLED), 0 keys only-in-one-file. Exactly what you expected — green-light the rollout.

• Sanity-check a `.env` extracted from a docker-compose `environment:` block

  You're porting a docker-compose service to k8s and need to turn the `environment:` YAML map into a `.env` ConfigMap. Paste your converted `.env` here, the syntax check flags two lines where you forgot quotes around values with `:` or spaces. Fix the two lines, copy back, apply.

• Audit a `.env` someone shared via Slack before storing it in 1Password

  A teammate sent you a `.env` for a service you're picking up. Before storing in your password manager you want to know: any keys missing the standard set? any obvious leaks? any duplicates? The all-checks view answers all three in one screen — and the "Mask secrets" toggle lets you screenshot the result safely for your handoff doc.

Common pitfalls

• Pasting a real production `.env` to test the tool. The parser stays in your browser, but pasting prod secrets into ANY web form is a habit you don't want to build. Duplicate the file, blank the values, paste the blanked copy.

• Expecting `${VAR}` to interpolate values from another file. Interpolation only resolves keys defined earlier in the SAME input — the same as Node `dotenv-expand`. Cross-file resolution belongs in your runtime, not in a static linter.

• Quoting numbers and booleans. `.env` values are always strings — `PORT=3000` and `PORT="3000"` produce the same string. The double-quotes only matter if your value contains a newline, a `#`, or leading/trailing whitespace you want preserved.

• Putting `export KEY=value` in a `.env` that gets loaded by Node `dotenv` and being surprised when `export ` ends up in the key. Node `dotenv` strips a leading `export ` per the convention; the tool follows the same rule. Bash-only or k8s ConfigMap consumers will NOT strip it — switch the file to plain `KEY=value` for portability.

• Treating an empty value as 'absent' for required-key checks. `KEY=` (empty) fails a `required` schema check the same as a missing line — that matches what most config libraries do. If empty is genuinely intentional, mark the key `optional:` in the schema.

• Hoping the secret scanner catches custom internal tokens. It catches the eight common patterns (AWS, GitHub, OpenAI, Stripe live/test, Slack, JWT, generic high-entropy). For an internal token shape your team uses, add it to your linter / gitleaks config — no client-side scanner can know your specific format ahead of time.

Privacy