Skip to content
Privacy

Everything runs in your browser. We never see your secrets. How we prove it →

ENV File Diff — Compare .env Files

Drop in two .env files. Variables are matched by name, grouped as added, removed or changed, and can be masked before anyone sees your screen.

Original
Changed

How .env files are read as keys, not lines

The .env format never had a specification. It grew out of shell sourcing plus a handful of loader libraries, and those loaders disagree: some strip an `export ` prefix, some expand `${VAR}` inside double quotes but not single ones, some treat a `#` after a value as a comment and some keep it. Order carries no meaning either, since a loader reads the whole file into a map before anything asks for a key. Run a line-based comparison over two such files and it will cheerfully report that thirty variables moved, when the truth is that one password rotated. So each side is parsed into keys first: prefixes dropped, quotes unwrapped, `=` signs inside values preserved, trailing comments trimmed.

What comes back is three lists — names found only on the right, only on the left, and on both with differing values — so "staging has no REDIS_URL" reads straight off the page instead of being inferred from scrollbars. Repeated keys are surfaced rather than collapsed, annotated with the fact that your loader will use the last assignment. A masking switch swaps every value for dots while leaving key names and verdicts legible, making the result safe to put on a shared screen mid-call. For configuration that nests — Helm values, pipeline definitions, application settings — YAML Diff applies the same key-first idea to a tree.

Credentials that must not travel

A .env file is an inventory of production credentials: database passwords, payment-provider secret keys, signing tokens, cloud access pairs. Those must never be pasted into an AI chat window or handed to an online formatter, because the instant they land in somebody else's logs they count as compromised and the only honest remedy is rotating every one of them. This page has no server side that could leak them: parsing and comparison are script running in your tab, and masking hides values even from the person behind you. Open your browser's network tab while you use this tool — you'll see no request carries your content. Check it before trusting it.

Where a key-based comparison earns its keep

  • A platform engineer promoting a release diffs the staging variable set against production before cutting over. The changed group is empty, the missing group holds one name, and a telemetry endpoint turns out to be why traces stopped arriving last Thursday.
  • A developer on their first morning lines up the .env.example committed to the repo against the file a teammate messaged over. Every key the example declares but the local copy lacks lands in one group instead of being hunted for by eye.
  • An SRE writing the incident timeline compares the environment rendered inside the running container with what source control says it should be, and finds a stale queue name left behind by a manual hotfix nobody wrote down.
  • A contractor about to share their screen switches masking on before joining the call, so the client can review which keys moved between environments without a single secret rendering on the projector behind them.

Frequently asked questions

Is it safe to paste real secrets here?

As safe as opening a text editor. Nothing typed is transmitted, the comparison is done by script already loaded in the page, and no account or history exists to keep a copy. We would still say this plainly: any credential pasted into a tool you have not checked yourself deserves rotating. Verify this one first.

What are the size and parsing limits?

Live comparison runs to roughly 1 MB combined, which is thousands of variables — well beyond any real environment file. The parser deliberately does not resolve interpolation: if one side sets HOST=${BASE}/v1 and the other spells the same URL out in full, the two values are reported as different, because textually they are.

Why not just use an ordinary line diff?

Because the two files are almost never in the same order. Insert one variable at the top of a fifty-line file and a line-based comparison paints fifty-one lines as moved. Keys are unordered by definition — the loader builds a map — so matching on name gives the three answers that matter: what appeared, what vanished, what changed value.

How are duplicate keys handled?

They are listed explicitly. Repeating a name is legal here and most loaders keep the final assignment, so that value drives the comparison while the earlier one is flagged as shadowed. Duplicates are a common cause of "I edited it and nothing happened", and they are almost invisible in a normal side-by-side read.

Does it understand export prefixes and quoting?

Yes. A leading `export ` is stripped, single and double quotes are unwrapped, an `=` inside a value stays part of the value rather than acting as a second separator, and a `#` beginning a trailing comment is removed while a `#` inside quotes survives. Blank lines and whole-line comments are ignored on both sides.