Env Example Checker · Config
Catch the env vars missing from your .env.example.
Paste your code and your .env.example to find the env vars your code reads but the example is missing — plus keys nothing reads — entirely in your browser.
Env Example Checker playground
Processed entirely in your browser — contents are never uploaded.
Tip: press Esc to release focus.
No share links on this tool — inputs may be secrets.
Load an example or paste your own code and .env.example, then check to see which variables drifted.
The Gap
.env.example always drifts.
A new variable lands in the code and your local .env — and the .env.example, the file actually committed to the repo and copied by every teammate, is quietly left behind. .env is git-ignored, so nothing warns you. That environment variable drift between code and config stays invisible until someone clones the project and the app crashes on a missing key, or missing env vars break a CI pipeline because a required variable was never documented.
Checking it by eye across a sprawling codebase is exactly the kind of mechanical diff a tool should do. This checker reads both directions at once: it lists the variables your code uses but the example is missing — the ones that break a fresh checkout — and the keys the example still declares that nothing reads, so you can prune the stale ones with confidence.
Want to see it first? Jump to the two inputs or try the live playground above.
The Pipeline
How it works.
Five deterministic steps diff your code against your example — all inside your browser tab, every time.
-
Scan the code.
Your source is swept for every environment-variable read — process.env, os.environ, $NAME and the rest.
-
Parse the example.
Your .env.example is read as KEY=value lines, with comments and blank lines skipped, into a key set.
-
Diff the two sets.
The names used in code are compared against the keys declared in the example, both directions at once.
-
Surface the gaps.
Variables used but undeclared are flagged as missing; declared-but-unread keys are flagged as unused.
-
Fix & re-check.
Add the missing keys to your example, prune the stale ones, then run again until the report is clean.
The Inputs
Two inputs, both familiar.
The checker reads exactly two things: your application code and your .env.example. If you have written either before, these will feel like home.
The code
Any source that reads environment variables. The scanner recognises process.env.NAME and import.meta.env.NAME in Node / Vite, os.environ["NAME"] / os.getenv("NAME") in Python, os.Getenv("NAME") in Go, and bare $NAME in shell.
// server.ts
const port = process.env.PORT ?? '3000';
const dbUrl = process.env.DATABASE_URL;
const apiKey = process.env["STRIPE_SECRET_KEY"];
if (!dbUrl) {
throw new Error('DATABASE_URL is required');
}The .env.example
Standard dotenv lines — KEY=value per line, with # comments and blank lines ignored. Only the key names matter for the diff, so placeholder values are fine. This is the file your teammates copy to a real .env.
# .env.example
PORT=3000
DATABASE_URL=postgres://localhost:5432/app
# STRIPE_SECRET_KEY is used in server.ts but
# was never added here — the checker flags it.
# Declared below but nothing reads it — flagged as unused.
LEGACY_FEATURE_FLAG=falseComing Soon
Fail the build on drift.
The browser checker is step one. A drop-in CLI will run the identical diff over your repo in CI, so a forgotten .env.example entry fails the build instead of breaking a teammate's first git clone.
A first-party GitHub Action that wraps the CLI is planned alongside it. Both are coming soon — the in-browser checker above works today.
# Coming soon — the same check in CI
$ envcheck ./src --example .env.example
✗ Missing from .env.example (1)
STRIPE_SECRET_KEY used in src/server.ts
! Unused in .env.example (1)
LEGACY_FEATURE_FLAG
1 missing, 1 unusedA Note on Scope
How the detection works: the checker matches environment-variable reads by their common, literal access patterns — process.env.NAME, os.environ["NAME"], $NAME and the like. Names built dynamically at runtime (for example process.env[someVariable]) can't be resolved statically, so they won't appear in the used set. Treat a clean report as strong confidence that your documented config matches your code — and still skim any computed lookups by hand.
FAQ
Questions, answered.
Tap a question to expand the answer.
What does the Env Example Checker do?
It compares the environment variables your code actually reads against the keys declared in your .env.example. Paste both, press Check, and it reports two gaps: variables used in code but missing from the example (the ones that bite a new developer or a fresh deploy), and keys declared in the example that nothing reads (stale entries worth pruning). Everything is computed in your browser.
Does my code or .env.example ever leave my browser?
No. The checker runs 100% client-side. Your source and your example file are parsed and diffed in your browser tab — nothing is uploaded to a server, and there is no account or signup. It is safe to paste internal code and config keys.
Which languages and access patterns does it detect?
It recognises the common ways code reads environment variables across popular ecosystems — process.env.NAME and process.env["NAME"] in Node and TypeScript, import.meta.env.NAME in Vite, Deno.env.get("NAME") in Deno, os.environ["NAME"] / os.getenv("NAME") in Python, ENV["NAME"] / ENV.fetch("NAME") in Ruby, os.Getenv("NAME") in Go, System.getenv("NAME") in Java, and getenv / $_ENV["NAME"] in PHP. The .env.example side is parsed as standard KEY=value lines, ignoring comments and blanks.
Why does .env.example drift from the code in the first place?
A new variable gets added to the code and the local .env, but .env.example — which is the file committed to the repo and the one teammates copy — is forgotten. The drift is invisible until someone clones the project, copies the example, and the app crashes on a missing key, or until a deploy fails because a required variable was never documented. This tool surfaces that drift before it ships.
Can it tell which missing variables are required versus optional?
It reports every variable the code reads that the example does not declare; whether a given variable is strictly required is a judgement only your code can make (a default fallback may make it optional). Treat the missing list as the set to review and document — add each to .env.example with a safe placeholder or a comment noting it is optional.
How do I find env vars used in code but missing from .env.example?
Paste your source code into the code panel and your .env.example into the template panel, then press Check. The checker scans the code for all environment-variable references — process.env.X, os.getenv("X"), import.meta.env.X and similar patterns — and diffs that set against the keys in your .env.example, listing every variable the code reads that the example file does not declare.
How do I find unused keys in my .env.example file?
The checker runs the diff in both directions at once. Alongside the missing-key report it also lists every key your .env.example declares that does not appear in the pasted code, so you can safely remove stale or leftover variables and keep the template lean and accurate.
How do I stop missing env vars from breaking CI or deployments?
Run this checker before committing so any variable your code reads but the example omits is caught early. Keeping .env.example in sync with code gives CI pipelines and teammates a complete template, which means the app fails fast at configuration time rather than crashing at runtime with an undefined variable error. A CLI version for automated checks in CI is planned.
What is the difference between comparing two .env files and checking against code?
Comparing .env to .env.example diffs two config files against each other — it only knows which keys each file declares. This checker instead reads the actual source code to learn which variables are truly used, so it catches variables the code needs that are absent from every config file, and flags example keys the code never touches. That distinction is what makes it useful for detecting environment variable drift between code and config, not just between two config files.
Is this an official tool for any framework?
No. This is an independent, community utility and is not affiliated with or endorsed by any framework, runtime or dotenv library. It models the widely used .env / .env.example convention and common env-access patterns only to describe what it checks.
More free, private DevOps tools.
The Env Example Checker is one tool in OpsCanopy — a growing canopy of browser-based validators, converters and testers that never touch a server.
New to Docker? Read the Docker guide →
29 free tools, every one offline-capable — opscanopy.com works with no signup and nothing uploaded.
Validating config and pipelines? Pair this with the GitHub Actions Validator or the GitLab CI Validator to catch workflow issues before push, or browse the full tools directory.
Not affiliated with or endorsed by any framework, runtime or dotenv library. The .env / .env.example convention and env-access patterns are referenced only to describe what this tool checks.