What this checks
Paste two .env files and see exactly what differs: a key only in Original (removed), a key only in Changed (added), a key present in both with a different value (changed), or unchanged. This is built for the comparison people actually reach for a diff to do — .env.example against a real .env to catch a variable the template declares that never got set locally, or one environment's config against another to catch a value that quietly drifted.
The comparison uses each file's resolved variables, parsed with the same rules the real dotenv package uses (shared with .env Validator) — not a naive line-by-line text diff. That distinction matters in two ways: a key redefined twice in one file is compared using only its final value (the one dotenv would actually keep), and two lines that read differently but resolve to the identical value (an unquoted # silently truncating one of them, for instance) show up as unchanged, with a parsing warning underneath the input explaining why.
What it doesn't do
This doesn't mask or redact values in the diff — the whole point is seeing what actually changed, and everything runs locally in your browser regardless. It also doesn't validate either file on its own beyond what's needed to resolve values correctly; for the full breakdown of what's wrong with a single file, use .env Validator.
FAQ
Why would two visually different values show up as "unchanged"?
Because the diff compares what each file actually resolves to at runtime, not its raw text. PASSWORD=abc#123 and PASSWORD=abc read differently, but dotenv truncates the first one at the unquoted #, so both actually set the same value — and the parsing warning shown for that file explains exactly why.
Why hide unchanged variables by default?
In a typical comparison — two environments, or a template against a real config — most variables are identical and only a handful actually matter. Hiding the noise by default (with a one-click toggle to bring it back) keeps the result focused on what changed.