Skip to content
R3XTools

.env Tools

Read an environment file, find what is wrong with it, and generate a safe .env.example.

.env

Paste or drop a .env file

It stays in this tab — there is no upload step

Secrets
0
Errors
0
Warnings
0

Analysis

Variables appear here as you paste.

Options
Values that look like credentials are masked until you ask for them.

Processed locally in your browser. Parsing, validation and redaction all happen in this tab. The file is never uploaded, and .env.example is generated locally.

Reference

Why this one never touches the network

A .env is the densest concentration of secrets most projects have. This tool is built as a pure function over a string: the parser, the checks, the masking and the .env.example generator all run in this tab, and the page makes no request while you use it. You can confirm that in your browser's network panel, which is a better assurance than a promise in a paragraph.

Quoting rules, and why they bite

Written asValue
A=hello worldhello world — unquoted values are trimmed, but spaces inside are kept.
A=value # notevalue — an unquoted # starts a comment, which silently truncates URLs containing fragments.
A='a # b'a # b — single quotes are literal. No escapes, no interpolation.
A="line\nbreak"Two lines — double quotes process escape sequences.
A="${B}/x"Interpolated against other variables. Single quotes would keep it literal.

The unquoted # is the one that costs an afternoon. Quote anything containing a URL fragment, a comment character or leading whitespace.

What counts as a secret

Two signals. The name — anything containing KEY, SECRET, TOKEN, PASSWORD, CREDENTIAL, AUTH, SALT or DSN. And the value — recognisable prefixes (sk-, ghp_, AKIA, xoxb-), PEM blocks, JWTs, long hex or base64 strings, and any connection string with a password in the authority.

Flagged values are masked in the table until you switch them on, and they are always emptied in the generated example regardless of that switch. The detection is heuristic: it will occasionally flag something harmless, and it can miss a secret with an unremarkable name and shape. Read the output rather than trusting it.

Generating .env.example

Comments, blank lines and ordering are preserved, so the example reads as a document rather than an alphabetised list of names. Values that are plainly configuration — numbers, booleans, short enum-like strings such as production — are kept by default, because a checked-in example with sensible defaults is more useful than a column of equals signs. Everything else is emptied.

Turn off Keep non-secret defaults if your policy is that an example file carries names only.

Questions

Is my .env file uploaded?
No, and this is the one tool where that is a design constraint rather than a preference. Parsing, validation, masking and .env.example generation are pure functions running in this tab, and the page makes no network request while you use it. You can verify that in your browser's network panel.
Why is my value being cut off at the # character?
In an unquoted value, # starts a comment — so DATABASE_URL=postgres://host/db#main silently becomes everything before the hash. Wrapping the value in quotes fixes it. This is the single most common .env bug and the tool flags it.
Should .env.example keep any real values?
Keep the ones that are configuration rather than credentials: ports, log levels, feature flags, NODE_ENV. A new developer can then run the project immediately and only has to fill in the secrets. Anything the tool flags as a secret is always emptied, whatever that setting is.