Duplicate Key Detector

Duplicate keys are the most deceptive error in a .env file because they are not an error at all to most parsers. A file can quietly contain DATABASE_URL=staging at line 4 and DATABASE_URL=production at line 61; whichever rule the parser uses silently ignores one of them, and your deploy connects to a database you thought you replaced.

The Duplicate Key Detector makes every repetition explicit. Each duplicated key is listed with every line number where it appears, the value each line supplies, and the surviving value under the parser model you choose — last-wins by default, first-wins on request, or with key casing normalized if you prefer.

A clean report with zero duplicates is proof the file is unambiguous. The scan is instant, deterministic and runs entirely in the browser — secrets never leave the page.

• Full duplicate report: every repeated key with all line numbers.
• Winner resolution: shows which value survives per rule.
• Last-wins default: matches common dotenv behavior.
• First-wins option: for parsers that keep the first value.
• Case-insensitive mode: treat FOO and foo as the same key.
• Summary counts: duplicates found and lines affected.
• Copy or download: clipboard or a .txt report in one click.
• Private: all scanning happens in your browser.

1. Paste your .env content into the input box, or load the sample which contains duplicates.
2. Choose the resolution rule and optional case-insensitive matching.
3. Click Detect. The report appears on the right.
4. Review each duplicate and remove the lines you no longer want.

Example 1 — Debugging a silent override. A developer's DEBUG flag never turned off even after editing; the detector shows DEBUG=true at two lines and exposes which one wins.

Example 2 — Merge reconciliation. After merging two .env files by hand, an engineer runs the detector and finds DATABASE_URL and API_KEY each defined twice.

Example 3 — Parser drift. A team moving between dotenv libraries flips the first-wins toggle to see how their values change under the new parser.

Example 4 — CI guard. A pipeline runs the detector and fails builds that add duplicate keys, keeping the .env unambiguous.

Example 5 — Case mixing. A contributor enabled case-insensitive matching and found app_name and APP_NAME both in the file, silently overriding each other on Windows-like parsers.

• Exposes silent overrides: duplicates become visible.
• Rule-aware: last-wins, first-wins, or case-insensitive.
• Line-exact: every occurrence identified.
• Deterministic: same file, same report.
• Secret-safe: a dedicated report, values shown only for duplicates.
• Private & free: browser-only, no account.