All Tools View Categories About Contact Privacy

.env File Linter

Lint a .env file for formatting and consistency and get a weighted health score with an actionable report.

Runs entirely in your browser — nothing is uploaded.

About .env File Linter

Teams that share a .env base quickly learn that formatting matters. One developer writes KEY = value with spaces, another key=value in lowercase, another leaves trailing spaces — and every parser, linter and formatter downstream treats the file differently. The file loads, but consistency is gone.

The .env File Linter quantifies that consistency. It scores the file out of 100, weighting each problem: invalid keys and duplicates cost heavily, while casing, spacing and empty values cost lightly. The report lists every deduction with its line number, and a toggle lets you declare lowercase-snake as your convention when that fits the project.

Run it on a freshly-edited .env before committing, or in your own review workflow — deterministic, line-precise, and entirely in the browser.

Features

  • Lint score: weighted 0–100 health rating for the file.
  • Consistency checks: spacing, casing, duplicates, empty values.
  • Line endings: CRLF/LF detection and mixed-ending warnings.
  • Ordering hint: flags keys that change the natural sort order.
  • Convention toggle: expect UPPER_SNAKE or lowercase_snake keys.
  • Actionable report: every deduction with line number.
  • Secret-safe: values are never echoed, only keys.
  • Private: all linting happens in your browser.

How to Use

  1. Paste your .env content into the input box, or load the sample.
  2. Pick the expected key convention (upper or lower).
  3. Click Lint. The score and detailed report appear on the right.
  4. Work through the deductions by line number and re-lint until the file is clean.

Examples

Example 1 — Pre-commit hygiene. A team adds the linter to their review habit; score dips below 100 whenever spacing or casing drifts, keeping commits uniform.

Example 2 — Onboarding. A new hire lints the base .env, sees the six deductions, and matches the project style instead of inventing their own.

Example 3 — Legacy cleanup. An engineer lints a decade-old .env, finds mixed casing and empty values, and normalizes it in one pass.

Example 4 — Multiple services. A platform team lints every service .env and refuses deploys below 90, enforcing consistency across repositories.

Example 5 — Formatter integration. A contributor runs the linter, fixes the spacing the report names, and the file now matches the project's pre-commit formatter output.

Benefits

  • Quantified quality: a score you can track over time.
  • Consistency enforced: casing and spacing rules applied evenly.
  • Line-precise: every issue points at its line.
  • Style-aware: upper_snake or lower_snake, your call.
  • Secret-safe: keys only, never values.
  • Private & free: browser-only, no account.

Frequently Asked Questions

What does this tool do?
It lints a .env for formatting and consistency: spaces around the equals sign, uppercase vs lowercase key style, empty values, duplicate keys, mixed line endings, trailing whitespace and a bar-chart style lint score.
How is the lint score computed?
Every issue subtracts points on a weighted scale — syntax problems cost more, style nits cost less. A score of 100 means a clean, consistent file; the report lists each deduction so you know what to fix.
What defines consistent key style?
By default the linter expects UPPER_SNAKE keys. If it finds keys in a different style, it reports them rather than guessing — and a toggle lets you switch the expected convention to lowercase.
Is my data uploaded?
No. Everything runs client-side in your browser. Nothing is sent to any server, stored or logged.
Does it duplicate the syntax validator?
Partly — it shares error detection — but it adds style and consistency checks with a score: key order stability, casing convention, empty values and group spacing, which the pure validator ignores.