Compare .env files by variable name, not by line
A normal text diff is the wrong tool for a .env file. Two files can hold exactly the same variables in a different order, with different comments and blank lines, and a line diff will light up like a Christmas tree anyway. What you actually want to know is smaller: is every variable the app needs defined, and does each environment hold the value you expect?
This checker answers that. It reads both files, matches variables by name, and sorts them into four groups: in sync, different value, only in the left file and only in the right file. Order, comments and blank lines are ignored.
Why .env files drift apart
It happens slowly. Someone adds a STRIPE_WEBHOOK_SECRET to their own machine because a feature needs it, and forgets the template. A teammate renames an API URL in staging and not in production. The .env.example file that was complete in January is missing six variables by June, and the first person to notice is whoever sets up a new laptop and gets a blank error page.
The painful version is a deploy. The code ships, the new variable is not defined in production, and the app starts up fine and then fails the first time that code path runs. Comparing the template with the real file before you deploy catches that whole category of mistake in about ten seconds.
How the comparison works
The parser follows the conventions most dotenv libraries share. It understands an optional export prefix, values in double quotes, single quotes or backticks, and double-quoted values that continue over several lines, which is how private keys are usually stored. In an unquoted value, a # that follows a space starts a comment, while a # in the middle of a URL stays part of the value. Windows line endings and a leading byte order mark are handled, and if a variable is defined twice, the last one wins, just as it does when the file is loaded.
Two limits are worth knowing. Values are compared exactly as written, so a reference such as ${HOST} is not expanded. And a line that cannot be read, such as a name that starts with a digit or a quote that never closes, is skipped and listed under that file so you can fix it.
Reading the result
Only in the left file usually means the right file is out of date: a variable the template expects that the real file never received. Only in the right file is the opposite, often a variable someone added locally and forgot to document, which is how a template quietly goes stale.
Different value is not automatically a problem. A database URL should differ between development and production. What deserves a second look is a value that was supposed to match, a feature flag left on in one place, or the “empty on one side” case, where the variable exists in both files but only one of them has actually been filled in. That last one passes a simple does-the-key-exist check and still breaks the app, so it gets its own label.
If you only care whether the same names exist, tick Compare names only. Values are ignored and a variable counts as in sync whenever both files define it, which is the right mode for checking a template against a real file.
A two-minute routine before every deploy
Compare .env.example with the file your production environment actually uses. Add anything listed under only in the left file, delete or document anything listed under only in the right file, then look at the different-value list with fresh eyes. Doing this after every release, or whenever a new variable is added, keeps the template honest for the next person.
If you use AI coding assistants, this is also a good moment to write down what they should leave alone. A short rules file that spells out what the assistant may and may not touch, your .env files included, is easy to produce with our CLAUDE.md and AGENTS.md generator.
Share the differences, not the secrets
When a build fails and you need help, pasting the whole .env into a ticket or a chat is how credentials leak. The report this tool builds lists variable names only: what is missing, what differs and what is empty on one side. It is safe to paste anywhere.
Some variables hold tokens you will want to inspect. If one of them is a JWT, read its claims and expiry with the JWT decoder, which also works entirely in your browser. And if you are turning a working curl request into code that reads its URL and key from the environment, the cURL to fetch converter does the conversion for you.
Frameworks and runtimes
The same file means slightly different things in different places. In Next.js, any variable starting with NEXT_PUBLIC_ is copied into the browser bundle, so it is public by design and must never hold a secret. The filter box makes it easy to scan all of those names at once. Node.js, Bun and Deno can all load a .env file without a library now, so the habits above apply whichever you choose, and if you are still weighing the third one, our post asking is Deno dead explains where it stands. Working on a Next.js app? The middleware matcher tester is another browser tool built for it.
Why this runs in your browser
A .env file is about the most sensitive text a developer handles, which is exactly why a tool that uploads it just to compare two files makes little sense. Here the parsing and comparing happen on your device, and values are masked on screen until you ask to see them. You can confirm it yourself: open your browser's Network tab, paste two files and watch for requests. There are none. More tools built the same way are collected in our free developer tools.