ENV file validator

Paste your .env file and see the mistakes that break configuration: repeated keys, invalid names, unclosed quotes, spaces where they should not be. You can also make a copy with the secrets hidden.

  • Free
  • No sign-up
  • Runs in your browser
env-file-validator

100% private — your text is processed in your browser and never sent to any server.

How it works

Paste the file

The whole .env, with comments and blank lines if you like.

Read the report

Each problem comes with its line number.

Make a safe copy

Get a .env.example with names only, or a copy with hidden values.

Small mistakes in a .env file, big problems in production

A .env file stores configuration, such as database addresses, keys and feature flags, as simple NAME=value lines that an application reads when it starts. The format looks trivial, but there is no official standard and every tool reads it a little differently. A repeated name, a missing quote or a space in the wrong place can silently give you a wrong value, and the result is a bug that only shows up on the server. Checking the file takes seconds.

What is checked

  • Lines that are not NAME=value, which most parsers skip without a word.
  • Invalid names. Names should use letters, digits and underscores, and not start with a digit.
  • Duplicate names. If a variable is set twice, one of the values is ignored, usually the first.
  • Quotes. A quote that never closes swallows the following lines, and text after a closing quote is a mistake.
  • Spaces. Spaces around the equals sign or unquoted values with spaces are read differently by different tools.
  • Empty values, lowercase names and the export prefix. These are reported as notes, since they are not always errors.
  • Invisible characters such as a BOM at the start, which can break the name of the first variable.

Secrets and .env.example

A .env file usually holds secrets and must not go into version control. The tool lists the variables that look sensitive by their name, such as those with PASSWORD, SECRET, TOKEN or KEY. Its most useful trick is the .env.example option, which turns your file into a list of names with empty values, safe to commit so that others know which variables the project needs. You can also get a copy with the values replaced by asterisks to share for support.

Limits

The check follows the widely used conventions of dotenv-style libraries. Some tools have extra features, such as variable expansion with ${OTHER}, that are not checked here. Because a .env file holds secrets, nothing you paste is sent anywhere: it is checked in your browser and disappears when you close the page.

Frequently asked questions

How do I check a .env file for errors?
Paste the contents and choose Check for problems. Each mistake is listed with its line number.
Is it safe to paste my .env file here?
Yes for this tool, because it works entirely in your browser and sends nothing. As a general habit, still avoid pasting real secrets into sites you do not trust.
How do I create a .env.example?
Choose Make a .env.example. You get the variable names with empty values, which is safe to commit.
What happens with a variable defined twice?
Most parsers keep only one of the values, often the first. The tool reports the repeated name and the line of the first definition.
Should I put quotes around values?
Yes when a value has spaces, a # sign or special characters. Otherwise the parser may cut it or read it wrongly.
Does it support multi-line values?
Yes, quoted values can continue over several lines, as many dotenv libraries allow.