Skip to main content
lab.golamrabbani.org

.env File Validator

Validate a .env for duplicates, quoting, weak secrets, and bad export.

Written by Golam Rabbani, Founder & Lead Engineer

Paste a .env file to check for common mistakes: invalid keys, duplicates, mismatched quotes, unquoted whitespace, inline comments, weak secrets, and misuse of export. Everything runs locally.

How to use this .env file validator

  1. Paste your .env file into the text area.
  2. Click Validate to scan every line for syntax and style problems.
  3. Read the findings list — each entry shows line number, rule ID, severity, and what to fix.
  4. Fix the lines in your editor and re-run the validator until the report is clean.
  5. Click Copy report to grab a plain-text version for a pull-request review comment.

About this .env file validator

The .env file validator runs a deterministic ruleset over your environment file in the browser to catch the mistakes that trip up dotenv, docker-compose, systemd, and shell `source`. It walks the file line by line, joining nothing — env files do not have continuations — and emits a finding for each problem with a stable rule ID like `E002` (no `=`) or `W003` (unquoted whitespace).

Checks cover both syntax (mismatched quotes, missing `=`, duplicate keys, invalid identifiers) and convention (the `export` keyword that shells accept but dotenv ignores, unquoted whitespace that breaks in some loaders, inline `#` comments after unquoted values). It also flags keys that look like secrets (PASSWORD, SECRET, TOKEN, API_KEY) when their values are short or obvious placeholders like `changeme`.

For example, this input:

NODE_ENV=production PORT=3000 API_KEY=changeme DATABASE_URL=postgres://u:p@h/db name NODE_ENV=development

returns: W001 line 2 (leading whitespace), W004 line 3 (API_KEY value is a placeholder), W003 line 4 (unquoted value contains whitespace), and E006 line 5 (duplicate `NODE_ENV`). Severities sort into error, warning, and info so reviewers can triage at a glance. All checks run client-side; the .env contents never leave the browser.

FAQ

Does the validator support the export prefix?
It recognises it and emits an info-level finding (`I001`). `export KEY=value` works in POSIX shells but most env-file loaders (dotenv, docker-compose, foreman) treat it as either an invalid key or a no-op. For portability, drop the `export` prefix from .env files.
How does it detect duplicate keys?
It tracks every key it has already seen and reports the second (and subsequent) occurrence as `E006`, with a back-reference to the line where the key was first defined. Most loaders silently keep either the first or last value — the result is non-deterministic until you fix the duplicate.
Why does it warn about unquoted whitespace?
Some loaders treat trailing or interior whitespace as part of the value; others strip it. The difference between `KEY=hello world` working in your local shell but breaking in docker-compose is exactly this. Wrap whitespace-containing values in double quotes (`KEY="hello world"`) for consistent behaviour.
What counts as a "weak secret"?
The validator looks at keys whose names contain hints of secret intent — PASSWORD, SECRET, TOKEN, KEY, API_KEY, PRIVATE, AUTH, CREDENTIALS — and flags values that are shorter than 8 characters or match a list of obvious placeholders (password, changeme, 123456, admin, root, qwerty). It is a heuristic, not a real password-strength check.
Does the validator send my .env contents anywhere?
No. Every check runs in your browser; the contents are processed locally and never uploaded, logged, or stored. Closing the tab discards the input.
Is this .env file validator free to use?
Yes, it is completely free with no account, no signup, and no usage limits.