.env File Formatter and Validator
Lint a .env file for the classic silent bugs, then format, sort or blank it into an example file — entirely in your browser, because these files hold secrets.
There is no .env specification
.env files look simple enough that everyone wrote their own parser, and they do not agree. There is no RFC, no working group, no reference implementation — only a shape that caught on. The disagreements land in the same three places every time: what ends a value, what quotes mean, and what happens to whitespace.
| Line | Value here | Why it is ambiguous |
|---|---|---|
KEY=value # note | "value # note" | some loaders strip from the hash, some keep it |
KEY=pa#ssword | "pa#ssword" | a hash is a fine password character |
KEY="value" | "\"value\"" | many loaders strip the quotes; this one keeps them |
KEY= value | " value" | many loaders keep it in the value |
Every one of those is a warning here, never an error. An error means the line cannot be a variable at all. A warning means it will load, and what it loads depends on which library reads it — which is the honest thing to say about a format with no standard.
And what is not ambiguous
| Line | Value | Rule |
|---|---|---|
export KEY=value | "value" | export prefix is stripped |
KEY=a=b=c | "a=b=c" | value is everything after the first equals |
KEY =value | "value" | space before the equals is trimmed off the key |
The equals rule matters more than it looks. Splitting on the first equals is what
lets a base64 token like YWJjZA== or a connection string full of query
parameters survive intact. A parser that split on every equals would mangle both.
Parsing and validating are separate steps, deliberately
The key pattern is [^=]+ — anything at all, as long as it has no equals sign in
it. Names are checked afterwards, by a separate rule:
| Line | Key as parsed | Errors |
|---|---|---|
MY KEY=v | "MY KEY" | 1 |
9KEY=v | "9KEY" | 1 |
my_key=v | "my_key" | 0 |
KEY-NAME=v | "KEY-NAME" | 1 |
"KEY"=v | "\"KEY\"" | 1 |
All 5 parse; 4 are then rejected by name and 1 is accepted with a convention warning. That split is worth copying. A parser that refuses to read a malformed line cannot tell you what is wrong with it; one that reads it first can point at the exact key and say why.
Which is why a seven-line sample here produces 1 error and 6 warnings, and a clean file produces nothing at all.
How to use
- Paste your .env file contents.
- Read the warnings for quoting, spacing and duplicate keys.
- Fix what it flags.
- Generate a blanked example file to commit instead of the real one.
Frequently asked questions
Does my file get uploaded?
No, and this matters more here than almost anywhere. A .env file is by definition a collection of credentials, so it is parsed entirely in your browser and nothing is transmitted. You can disconnect from the network and the tool still works.
What is the commonest silent bug?
Spaces around the equals sign. Many parsers treat the space as part of the key or the value, so a key with a trailing space never matches and a value gains a leading one. The application then behaves as though the variable were unset, with no error to explain why.
Should values be quoted?
Only where they need to be — values containing spaces, hash marks or line breaks. Quoting everything is harmless in some parsers and produces literal quote characters in others, which is exactly the sort of inconsistency that makes .env files frustrating.
Why does a hash inside my value truncate it?
Because most parsers treat an unquoted hash as the start of a comment, so everything after it is discarded. Passwords containing a hash are a frequent casualty. Quoting the value resolves it.
What happens if a key appears twice?
It depends on the parser — some take the first occurrence and some the last, and neither warns. Duplicate keys are almost always an accident from merging or editing, and the resulting behaviour is unpredictable across environments.
Should a .env file be committed to version control?
No. Commit an example file with the keys present and the values blanked, so that anyone setting the project up knows what is needed without receiving the secrets. Committing real credentials is one of the most common ways they leak, and removing them from history afterwards is genuinely painful.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.