Share an env file safely
Runs locally in your browser. Your file never leaves your device.
By processing a file or pasted text here, you agree to the Terms.
Drop a .env or config file here — or
.env, YAML, TOML, INI, or flat JSON, up to 2 MB. Keys and comments stay; values get masked.
…or paste config text instead
Review these — possibly secret
Random-looking strings that match no known secret format — including any hiding in comments, which this tool never edits. They were not masked, because a high-entropy string can be a key or just a checksum — only you can tell. Their lines are marked in the scrubbed pane below.
Original
Scrubbed
How .env files end up shared
Nobody plans to publish a credentials file, and yet .env files keep landing in places they shouldn’t: pasted into an onboarding doc so the next hire can “just copy the values,” attached to a ticket because support asked for the full config, dropped into a GitHub issue or an AI chat as “here’s my config, what’s wrong with it?”. The file that exists precisely to keep secrets out of your code is the one file people hand around whole when something breaks — and the same goes for the YAML values file, the TOML service config, and the legacy INI. Once it lands in a ticket system, a chat transcript, or a screenshot, you no longer control where it goes.
The classic advice — “remove the sensitive lines first” — quietly ruins the reason you were sharing the file. So people skip it, or they do it by hand and miss one. An online tool that uploads your config to clean it is the same problem wearing a different hat. This page is a static site with no backend: the scrubbing runs in your browser, enforced by a Content-Security-Policy that forbids this page from making network requests at all.
Why masking values beats deleting lines
Whoever reviews your config needs its shape: which keys exist,
in what order, which are set and which are empty, which two settings
hold the same value. That is usually the whole diagnosis — a missing
key, a staging value in production, a password set where a socket path
was expected. So this tool keeps every key and masks the value:
DB_PASSWORD=tr0ub4dor.3 becomes
DB_PASSWORD=[SECRET-1], a quoted value keeps its quotes, a
YAML block scalar keeps its indentation, and comments stay word for
word. Repeated values get the same token, so “these two keys are set to
the same secret” is still visible — the structure survives, the value
does not.
Two kinds of detection run, and they reinforce each other. Values under
credential-shaped keys — password, secret,
token, auth, api_key and
relatives, in any of the supported syntaxes including
export-prefixed and multiline values — are masked whole,
even when the value itself looks harmless (a 16-character hex token is
indistinguishable from a commit hash, but under
push_token it gets masked anyway). Inside every other
value, the same pattern engine that powers this site’s
log file redactor masks emails,
IPv4/IPv6 addresses, JWTs, AWS keys, and Bearer tokens — so
DB_HOST=10.0.4.21 is masked by what the value is, not what
the key is called. Placeholders like
$${VAULT_ADMIN_PASSWORD} and flags like
false are recognized as non-secrets and left alone.
What it can miss — read this before you share
Detection is pattern-based and best-effort — expand for what can slip through.
Detection is pattern-based and incomplete by construction; any tool
claiming otherwise is overpromising. The specific gaps here: a secret
under a bland key name — ENDPOINT, DSN, a
vendor-specific name the heuristic doesn’t know — is only caught if the
value matches a pattern or is long and random enough for the
suspicious-string flagger (random strings under about 20 characters
slip beneath its statistical floor). Comments are deliberately never
edited, so a secret pasted into one stays — the flagger will mark a
random-looking string in a comment for your review, but a
prose-shaped password there is invisible to it. Exotic or deeply nested
formats (XML, HCL, templated Helm values) fall back to generic
line-by-line detection without format-aware handling. And it can
over-mask: auth: enabled looks exactly like a credential
assignment, and masking it is the safer failure. The side-by-side
preview highlights every changed line so the final human review takes
seconds, not minutes.
Practical limits
Files are processed entirely in this tab’s memory with a 2 MB ceiling — generous for config files, which are rarely over a few kilobytes. If what you actually have is a big log with config lines in it, use the log file redactor (same engine, 20 MB, built for logs). And if your JSON is deeply nested — an API response, an export, a payload — use the JSON redactor, which walks the full tree; this page treats JSON as flat key-value lines. The page works offline once loaded, and nothing persists after the tab closes.
Frequently asked questions
Which formats does it support?
.env files (including export prefixes, quoted values, and multiline quoted values), YAML (including | and > block scalars), TOML (including """ multiline strings), INI, and flat JSON configs. The format is detected from the file name or content, and you can override it. Anything else still gets the generic line-by-line detection — the same engine as the log file redactor on this site — it just won’t get the format-specific handling of comments and multiline values.
Does the scrubbed file stay valid?
That is the point of masking values instead of deleting lines: keys, separators, quotes, indentation, section headers, and comments all stay where they were, and only the value text is replaced. A quoted value keeps its quotes, a YAML block scalar keeps its indentation, and flat JSON stays parseable. The one caveat is meaning, not syntax: a masked value like [SECRET-1] obviously won’t work if someone runs the config as-is — it is for reading, not executing.
Does this page upload my config anywhere?
No. This is a static page with no server behind it, and its Content-Security-Policy is set to connect-src ‘none’ — the browser itself refuses to let this page make any network request, to us or to anyone. You can verify that: open DevTools, watch the Network tab, and load your file — no request carries your data. Everything runs in this tab’s memory and nothing persists after you close it.
Why mask values instead of deleting the lines?
Because whoever you are sharing the file with needs its shape. “Here’s my config, what’s wrong?” only works if the reviewer can see which keys exist, in what order, and which ones are set — DB_PASSWORD=[SECRET-1] tells them the password is present and where it lives, without telling them the password. Deleting lines destroys exactly the structure the reviewer needs, and repeated values get the same token, so “these two keys hold the same value” survives too.
What happens to comments?
They are preserved verbatim, on purpose — comments are the context a reviewer needs, and pattern-masking inside prose can’t be structure-aware. That cuts both ways: a secret pasted into a comment will NOT be masked. The suspicious-strings panel flags long random-looking strings anywhere in the output, comments included, so a leaked key hiding in one is pointed out for you to fix by hand — but the final read-through of comments is yours.
Can it miss secrets?
Yes. Key-based masking only triggers on credential-shaped key names (password, secret, token, auth, api_key and similar) — a secret stored under a bland name like ENDPOINT or DSN is only caught if the value itself matches a pattern or looks random enough to flag. Passwords made of ordinary words, secrets in comments, internal ID schemes, and random tokens under about 20 characters can all slip through. The side-by-side preview highlights every change so the final human review — the step no tool can replace — takes seconds. Never treat any automated scrub, this one included, as guaranteed.