WHAT IT DOES
Which variable is missing, not which line moved.
Paste two .env files and they are compared by key rather than by line, so reordering a file produces no differences at all. Each key is reported as added, removed, or changed, with the identical ones counted rather than listed. Values are masked by default and revealed only when you ask, because a .env file is a list of credentials and the usual question is which key differs rather than what the secret is. Quoting, inline comments, and export prefixes are resolved the way a dotenv loader resolves them, so the comparison reflects what your application would actually load.
Why use it?
Two environments can disagree because of a missing key or a changed value even when the files look similar. Key-based comparison helps locate that drift without immediately revealing every secret.
How to use this tool
- Paste the original and updated environment files into their labelled panes.
- Compare them with value masking enabled and review added, removed, and changed keys.
- Resolve each difference against the application's configuration requirements. Reveal a value only if needed; a changed key does not tell you which environment is correct.
Details and limitations
- Keys are matched by name, so two files with the same variables in a different order report no changes. A line-based diff would report every moved line.
- Values are hidden behind a character count until revealed, which is enough to spot a truncated or blank secret without putting it on screen.
- Quoting follows dotenv rules: a double-quoted value takes escape sequences, a single-quoted value is literal, and an unquoted value ends at an inline comment. A # inside quotes stays part of the value.
- An export prefix is ignored, so a file meant to be sourced by a shell compares against one meant to be read by a loader.
- A key defined twice is reported, with the last definition used, matching how a loader resolves the repeat.
- A variable set to an empty value on the right is called out separately, since a blank value overrides a default rather than falling back to it.
Compare environment files without exposing their values
Compare keys, not screenshots of secrets
Paste the original and updated .env contents into their respective panes. For the example below, LOG_LEVEL changes, CACHE_URL is added, and API_KEY disappears. You can establish those facts without revealing the values. Keep the default masking while recording or sharing the screen. Ordering differences are not the same as value changes, so inspect the key-based result rather than relying only on a text diff.
Original:
LOG_LEVEL=debug
API_KEY=DEMO_ONLY
Updated:
LOG_LEVEL=info
CACHE_URL=redis://localhost:6379Resolve each difference intentionally
An added key may be a new dependency; a removed key may be a deliberate cleanup or a deployment mistake. The tool does not know which environment is authoritative. Check the application's configuration contract before copying values across environments. Never assume a default suitable for localhost is safe for production, and do not use a real credential to make a public example look realistic.
Prepare a reusable example
Use the .env.example sanitizer when you need a file that describes the expected keys. Inspect its fixed retention rules and the list of kept values before committing the output. Comments and malformed lines are preserved, so review those separately for secrets. An example file documents configuration; it does not provision a service or manage secrets. A configuration loader can enforce required values at startup, while a diff only tells you how two supplied files differ.
Validate generated deployment files separately
For Nginx and systemd, a generated file is a starting point rather than a deployment. Nginx map and limit_req_zone directives belong in the http context, not inside a server block. Run nginx -t against the assembled configuration before reloading. For a systemd unit, use systemd-analyze verify against the saved unit and check paths, executable permissions, and the runtime user on the destination host. Passing a syntax check does not prove the service is reachable or correctly authorized.
nginx -t
systemd-analyze verify ./example.service