Environment Variable Checker

You inherited a project, the README says "copy .env.example to .env and fill in the values," and three weeks later your local environment runs but staging keeps crashing on a missing variable that nobody added to the example file. Diffing two .env files manually is tedious and easy to get wrong because comments, blank lines, and quote handling all interfere with line-by-line comparison.

Paste both files in. The output groups variables into added (in the new file but not the old), removed (gone from the new), and changed (same key, different value). Comments and blank lines are ignored. Keys are matched on name only — values are compared as strings, which means quoted and unquoted versions of the same value show as different even though most parsers treat them identically.

The parsing rule is the de-facto dotenv format used by most modern toolchains: KEY=value per line, optional comments starting with #, optional quoted values with single or double quotes. The checker tokenizes each file into a key-value map, ignoring blank lines and full-line comments, then compares maps. Order doesn't matter for correctness — a config file with the same keys in a different order is functionally equivalent — but the diff preserves the order from the new file so you can scan it linearly.

A worked example: your dev .env has DATABASE_URL, REDIS_URL, STRIPE_KEY, and AWS_REGION. Staging adds SENTRY_DSN and FEATURE_FLAGS_URL but is missing STRIPE_KEY entirely (oops). The diff shows: added (SENTRY_DSN, FEATURE_FLAGS_URL), removed (STRIPE_KEY), unchanged (DATABASE_URL, REDIS_URL, AWS_REGION). The "removed" group is the alarm bell — staging will crash when it hits a code path that needs the Stripe key. This kind of audit catches deployment-config drift before a customer does.

Where the checker is intentionally limited: it doesn't validate values, only flags differences. Two URLs pointing to different databases will show as "changed" with no opinion about which is right. It also doesn't follow shell expansion (${OTHER_VAR}); the literal string is compared. Some loaders support multi-line values via escaping or single quotes spanning lines — the checker treats everything as line-based, so multi-line values need to be flattened first. For sensitive operations, never paste production secrets into any web tool; do production diffs locally with the standard `diff` command and a checkout of the file from your config-management system. The browser-based checker is fine for development environments where the values are non-secret or already shared across the team.