.env Validator

How it works

Documentation

About .env Validator

Check .env syntax and duplicate variable definitions locally. Diagnostics identify the line and column of a problem; select one to navigate to that position in the editor. Validation checks syntax only, not application-specific environment semantics.

How to validate a .env file

Paste your text or choose an example, then select Validate .env. A valid document shows “Valid .env file”; duplicate definitions show “Valid .env file with warnings.” Syntax errors show “Input needs attention.” The Result pane never reproduces values or source lines.

Variable names

Names follow [A-Za-z_][A-Za-z0-9_]*: start with an ASCII letter or underscore, followed by letters, digits, or underscores. PORT, foo_bar, and _PRIVATE are valid. Names starting with digits, containing spaces, hyphens, dots, or non-ASCII letters are invalid.

Assignments

Use KEY=VALUE. Spaces and tabs are allowed before a key and around the equals sign: KEY = VALUE. Whitespace inside a key is invalid. An equals sign is required, so DATABASE_URL alone is invalid. Unquoted values may contain spaces, URLs, additional equals signs, backslashes, backticks, and shell-looking text as literal data.

Empty values

OPTIONAL=, EMPTY_QUOTED="", and EMPTY_SINGLE='' are valid empty values. A blank or whitespace-only document produces env.input.empty. A comment-only document is valid with zero variables.

Comments

A line beginning with #, optionally after spaces or tabs, is a comment. In an unquoted value, every # starts an inline comment, even without preceding whitespace: MODE=production#comment. Quote a literal hash, for example PASSWORD="abc#123" or PASSWORD='abc#123'.

Single and double quotes

Values may be enclosed in single or double quotes. Hashes, equals signs, dollar signs, and spaces inside quotes are literal. Single quotes end at the next literal single quote; a backslash has no escape meaning there. Inside double quotes, backslashes determine whether a quote is escaped: KEY="quote: \"hello\"" and KEY="backslash: \\" are valid. The validator locates quote boundaries without decoding escape sequences.

After a closing quote, only spaces, tabs, an optional hash comment, a line ending, or the end of input is allowed. KEY='value'#comment is valid; KEY="value"extra is invalid. Shell-style concatenation such as KEY=foo"bar" is unsupported. An unterminated quote is reported at its opening position.

Multiline values

Both single and double quotes can span multiple lines. Newlines inside quotes are literal. For example:

PRIVATE_KEY="-----BEGIN KEY-----
demo
-----END KEY-----"

export prefix

export PORT=3000 is valid when one or more spaces or tabs separate export from the name. exportFOO=value is an ordinary assignment to exportFOO. This prefix does not load or export anything in your browser.

Duplicate variables

Repeated names produce env.key.duplicate warnings, keeping the file syntactically valid. Names are case-sensitive: API_URL and api_url differ. Exported and ordinary definitions share the same name space. Variables counts every successfully parsed definition; Duplicates counts additional definitions. Three definitions of FOO mean Variables: 3 and Duplicates: 2. Definitions with syntax errors do not count.

Variable references

SyntaxDock does not load environment variables. SyntaxDock does not expand $VAR or ${VAR} references. ${VAR:-default} is also literal, and referenced names need not exist. Shell-looking text such as $(...) is never executed. Backticks are ordinary data, not a special quoting dialect. These sequences do not produce warnings merely for being present.

Portable .env syntax

.env files do not have one universal cross-tool specification. SyntaxDock validates a conservative, portable dotenv-style syntax. .env syntax varies between tools, so SyntaxDock uses a documented portable subset.

UTF-8 text in values and comments, blank lines, LF and CRLF line endings, and one optional UTF-8 BOM at the very beginning are supported. A BOM elsewhere is rejected. NUL, other C0 control characters except tabs and supported line endings, DEL, and lone carriage returns are rejected. Locations are 1-based; columns use the editor’s UTF-16 positions. Lines includes a final empty line after a trailing newline; CRLF counts as one line break.

Differences between dotenv implementations

Consumers differ in hash comments, escapes, interpolation, multiline values, accepted names, and which duplicate wins. Passing validation is not a guarantee of identical behavior in every dotenv library. This tool does not validate Rails, Node, Docker Compose, Vite, or Next.js environment semantics. It does not format, sort, deduplicate, fix, detect secrets, or check whether application code uses a variable.

Privacy

Processed locally — Your data stays in this browser. Source and values are not uploaded to Rails or external services, stored in browser storage, logged, or loaded from files. URLs in values are never requested. The parser retains variable names and positions, not a decoded map of values. Diagnostic messages may mention a variable name but never its value.

Limits

Input is limited to 1 MiB (1,048,576 UTF-8 bytes) and oversized text is rejected before parsing. At most 1,000 diagnostics are displayed, including a notice if more issues exist. Errors and warnings continue to be counted after the display limit. The Result pane shows Variables, Duplicates, Errors, Warnings, and Lines.

FAQ

Does this run shell commands or set my environment? No. It only scans text for syntax. Why is a duplicate valid? Repetition is a warning, not a syntax error; your actual consumer decides which definition takes effect. Why quote a hash? Every unquoted hash starts a comment in this contract. Will validation reveal my values? Results contain fixed validity text, counts, and value-free diagnostics.

Related tools

Use YAML Validator for YAML syntax, Docker Compose Validator for Compose configuration, or Kubernetes YAML Validator for Kubernetes manifests.