Merge .env Files Without Losing Track of What Changed
Add two or more .env files and this finds every key that conflicts between them. Pick which value survives, key by key, and download the result.
- Merge as many files as you need
- Finds every conflicting key
- Runs entirely in your browser
Why use a merger?
Two .env files rarely agree on every key. Diffing them by eye means scrolling back and forth trying to remember which file had the value you actually want.
This tool lines the files up, flags every place they disagree, and lets you decide once per key. Useful for migrating hosts, combining dev and prod configs, or resolving what a new teammate sent you.
How it works
- 1Upload or paste at least two .env files
- 2Click "Merge Files" to scan for conflicts
- 3Choose which value wins for each conflicting key
- 4Download or copy the merged file
When to Reach for the Merger
Four situations where merging by hand gets old fast
Project Migration
Move a project from one host to another, say Heroku to Vercel, and you end up holding both a Heroku-shaped .env and a fresh Vercel one. The merger combines them while you pick which values actually carry over.
Building a Staging Config
A staging environment usually wants some values from development and some from production, not a full copy of either. Pick each value from the source it should come from instead of rebuilding the file from scratch.
Onboarding a New Teammate
A new hire usually collects .env snippets from three different people before their app runs. The merger folds those fragments into one file without anyone having to remember what the backend lead already sent.
Monorepo Configuration
A monorepo often has a root .env with shared values and per-package .env files with overrides. Deploying one package means merging the root config into it and resolving whatever overlaps.
Deciding Which Value to Keep
What to check before you click a value and move on
Know what the variable actually does
A database connection string, an API endpoint, and a feature flag all deserve a different answer, and the right one usually depends on which environment you're building toward.
- Database URLs: pick based on which database you actually want to hit (dev, staging, prod)
- API keys:use the one tied to your target environment's account
- Feature flags: decide what should actually be on in the merged environment
- URLs and endpoints: match the deployment target, localhost for dev, a real domain for prod
Check which value is actually current
Files from different sources or different points in time drift. An API key might have been rotated since one of the files was last touched, or a database URL might point somewhere that no longer exists.
- When was each file last updated?
- Has anything been rotated since the older file was written?
- Is there a deprecated value that should be replaced instead of kept?
Verify after merging, not before deploying
Once the merged file exists, run the app against it before it goes anywhere near production.
Write down the non-obvious choices
When a merge decision isn't obvious in hindsight, a one-line comment in the file (or a note in your changelog) saves the next person, often you in six months, from re-deriving why that value won.
Frequently Asked Questions
Common questions about merging .env files