Why was a harmless value emptied?

Because no rule covered it. The list of rules is short on purpose: a hostname, an account name, or a bucket name can be private, and the cost of publishing one by accident is much higher than the cost of typing it back in. Anything kept is listed in the summary, so you can see exactly what the rules let through.

Is this enough to make my .env safe to commit?

It makes the .env.example safe to commit. It does not touch your .env, which should stay in .gitignore, and it cannot help with a secret that has already been pushed. A committed secret is compromised: rotate it rather than removing it in a later commit.

Does it change the structure of my file?

No. Lines stay in order, comments and blank lines are untouched, and only the text to the right of an = ever changes. That matters because the comments in a .env are usually the only explanation of what each variable is for.

Generators / LOCAL TOOL

.env.example Sanitizer

Turn a real .env into the .env.example you can commit, with every value emptied unless a stated rule keeps it.

Runs locally — input is never uploaded

InputPaste the contents of a .env file

OutputReady when you are

WHAT IT DOES

Blank by default, because a commit is forever.

Paste a working .env and get the .env.example that belongs in the repository. Every value is emptied unless one of a short list of stated rules keeps it, and the values that survive are named back to you so the decision can be checked rather than trusted. Comments, blank lines, ordering, and the export prefix are preserved, because a .env.example is also the documentation for the file it describes.

Why use it?

A real .env is useful as a list of configuration keys but unsuitable as public documentation. This tool prepares an example while making retained values reviewable.

How to use this tool

Paste or drop the source environment file locally.
Run the sanitizer and review which values were kept or emptied by its fixed rules.
Inspect comments and malformed lines separately before copying or saving the output; those lines are preserved and can still contain private information.

Details and limitations

A value is kept only when a rule covers it: a boolean or an environment or log-level word, a number, or a URL that points at this machine and carries no user information. Everything else is emptied.
A name that reads as a credential is emptied whatever its value looks like, so API_KEY=12345 does not survive on the grounds of being a number.
postgres://localhost:5432/app is kept and postgres://user:pass@localhost:5432/app is not, because the second one carries the password that must not be committed.
Names are matched as whole words rather than as substrings, so MONKEY_COUNT is not treated as a key and DESIGN_MODE is not treated as a signature.
Comments, blank lines, indentation, quoting, the export prefix, and a trailing comment on an unquoted value all survive unchanged.
A line that cannot be read as an assignment is copied through untouched and counted in the summary rather than dropped.

WORKED EXAMPLES

Keep a harmless log level, empty a credential

Use dummy data to see the fixed retention rules. The comment is deliberately harmless: comments and malformed lines are preserved, not automatically scrubbed.

Environment file

# Example settings
LOG_LEVEL=debug
API_KEY=DEMO_ONLY

Expected result

The output keeps LOG_LEVEL=debug and the comment, but writes API_KEY= with no value. Review the kept-value list and every comment before committing the file.

COMMON QUESTIONS

.env.example questions

Why was a harmless value emptied?: Because no rule covered it. The list of rules is short on purpose: a hostname, an account name, or a bucket name can be private, and the cost of publishing one by accident is much higher than the cost of typing it back in. Anything kept is listed in the summary, so you can see exactly what the rules let through.
Is this enough to make my .env safe to commit?: It makes the .env.example safe to commit. It does not touch your .env, which should stay in .gitignore, and it cannot help with a secret that has already been pushed. A committed secret is compromised: rotate it rather than removing it in a later commit.
Does it change the structure of my file?: No. Lines stay in order, comments and blank lines are untouched, and only the text to the right of an = ever changes. That matters because the comments in a .env are usually the only explanation of what each variable is for.