Why a line-based diff falls short
Running git diff or a generic text diff on two .env files compares them line by line. That reports differences in order, comments, and blank lines that do not matter, while making it hard to answer the real question: which keys exist in one file but not the other, and which keys have different values?
Environment files are really a set of key-value pairs, not an ordered document. Comparing them as a set of keys removes the noise and surfaces the differences that affect how the app runs.
What a key-aware comparison shows you
A proper .env comparison groups results by key across every file. It tells you which keys are present everywhere, which are missing from one environment, which appear only in a single file, and which are duplicated within a file. It can also flag malformed lines that would otherwise be parsed as garbage.
This is the difference between "line 14 changed" and "JWT_SECRET is set in prod but empty in qa" — the second is actionable.
How to compare .env files in the browser
Open the validator on this site and load one file as the reference template, then add the others as environments. You can paste them or drop up to four files at once. The tool parses each file and shows a per-key report: missing keys, undocumented keys, duplicates, and malformed lines, with each key linked to the exact file and line.
Everything runs locally in your browser, so you can safely compare real .env.dev, .env.qa, and .env.prod files without any of their contents leaving your machine.
Common reasons environments diverge
A variable added for a new feature reaches dev but not prod. A secret is rotated in one place and not another. A key is renamed in code, leaving the old name behind in one file. A value is pasted twice, so a duplicate silently overrides the intended one.
Diffing your environments by key on a schedule — or before each deploy — catches these before they cause an outage. It is the same comparison whether you have two files or four.