Why does a duplicate key matter if my .env file 'works'?

Most .env parsers (dotenv, python-dotenv, Rails' dotenv-rails) resolve duplicates by keeping either the first or the last occurrence depending on the library, silently discarding the other. The file often does 'work', just not with the value you think, which is exactly the kind of bug that's invisible until it isn't.

Why flag unquoted values with spaces?

Some parsers and, especially, shell-sourcing of a .env file (`export $(cat .env | xargs)`) will split an unquoted value on whitespace, truncating it at the first space. Wrapping the value in quotes makes the intent unambiguous across tools.

What's the issue with booleans/numbers stored as strings?

Every value in a .env file is a string, full stop, there's no native boolean or number type. `DEBUG=false` is still the three-character string `"false"`, and reading it with `if (process.env.DEBUG)` in JavaScript evaluates to true because any non-empty string is truthy. This report flags such values as a reminder to parse them explicitly (`=== "true"`, `Number(...)`) rather than truthy-check them directly.

Does this tool execute or evaluate my .env file?

No. It only parses the text line-by-line to check formatting and structure; nothing is executed, sourced, or sent anywhere. Comment lines (starting with #) and blank lines are skipped, matching how real .env parsers treat them.

.env File Validator - Find Duplicate Keys & Formatting Issues

Overview

Introduction

A .env file with a subtle problem, a duplicated key, a value silently truncated at a space, a "false" that's actually truthy, tends to fail quietly rather than loudly, and the resulting bug can take a while to trace back to the config file itself.

This tool parses pasted .env text and surfaces exactly those problems in a plain-text report, without executing or sourcing anything.

What Is .env File Validator?

A static checker for .env-formatted text: paste the contents of a .env file and get back a report covering five issue categories, duplicate keys, lines missing an `=`, unquoted values containing spaces, empty values, and values that look like booleans or numbers but remain plain strings.

Each category lists the specific line numbers and keys involved, or states "None found" when the file is clean on that dimension.

How .env File Validator Works

The input is split into lines; blank lines and lines starting with `#` are skipped, matching how real .env parsers treat comments. Every remaining line is checked for an `=`; lines without one are reported as malformed.

For lines with an `=`, the key (before the first `=`) and value (after it) are extracted. Keys are tracked in a map to detect duplicates; values are checked for surrounding quotes (to decide if internal whitespace is intentional), emptiness, and whether they match a boolean-like or numeric-like pattern after unquoting.

When To Use .env File Validator

Use it before committing a .env or .env.example file, or when debugging a configuration value that isn't behaving as expected.

It's also useful when reviewing a .env file inherited from another developer or an old deployment, to quickly spot accumulated duplicate or malformed entries.

Often used alongside .env File Generator and Secrets Manager Config Generator.

Features

Advantages

Checks five distinct issue categories in one pass, each reported with exact line numbers.
Understands quoting, so a deliberately quoted value containing spaces isn't flagged as an error.
Runs entirely on parsed text, no execution or evaluation of the file's contents.

Limitations

Doesn't validate values against your application's actual expected schema (e.g. that DATABASE_URL is a well-formed connection string).
Duplicate-key detection is case-sensitive and exact-match; it won't catch near-duplicates like `API_KEY` vs `APIKEY`.

Examples

A file with a duplicate key and an unquoted spaced value

Input

PORT=3000
PORT=4000
APP_NAME=My Cool App
DEBUG=false

Output

Environment Variable Validation Report
=======================================

Duplicate keys (1):
  - PORT (lines 1, 2)

Lines missing "=" (0):
  None found.

Unquoted values containing spaces (1):
  - Line 3: APP_NAME (wrap the value in quotes)

Empty values (0):
  None found.

Boolean/number-looking values stored as strings (1):
  - Line 4: DEBUG=false (your code must parse this manually, e.g. === "true" or Number(...))

PORT is flagged as a duplicate across both lines, APP_NAME's unquoted space is flagged, and DEBUG=false is flagged as a stringly-typed boolean.

Best Practices & Notes

Best Practices

Run new or inherited .env files through a check like this before relying on them, especially after merging config from multiple sources.
Quote any value that contains spaces, a `#`, or a quote character, regardless of whether your current parser happens to tolerate it unquoted.
Explicitly parse boolean/number-looking env values in code (`=== "true"`, `Number(...)`) instead of relying on truthy checks.

Developer Notes

Key/value splitting uses the first `=` on each line (`indexOf("=")`), so values containing `=` (connection strings, base64) are preserved intact; this matches how dotenv itself parses lines. Boolean/number detection uses two regexes, `/^(true|false|yes|no)$/i` and `/^-?\d+(\.\d+)?$/`, applied after stripping a single layer of matching surrounding quotes, so `DEBUG="false"` is still flagged (since it's still just a string once parsed) while `DEBUG="the value is false"` is not.

.env File Validator Use Cases

Pre-commit sanity check on a new or edited .env / .env.example file
Debugging a configuration value that isn't behaving as expected due to a duplicate key
Auditing an inherited or long-lived .env file for accumulated formatting drift

Common Mistakes

Assuming the last occurrence of a duplicated key always wins; the winning behavior actually depends on which parser library loads the file.
Treating DEBUG=false as falsy in JavaScript without an explicit string comparison, since any non-empty environment variable string is truthy.

Tips

Use the .env File Generator to produce a clean, section-grouped file from scratch, then run it through this validator as a final check before committing.

.env File Validator