Secrets/Config Redactor

Free

Paste a .env or config file and automatically mask API keys, passwords, and tokens next to sensitive key names or known secret formats (AWS, GitHub, Stripe, JWT, PEM). Safe to then paste into a chat AI or bug report.

Paste your file

Redacted result 0 masked

Recent Activity

Visible to everyone. Last 20 uses across all visitors, newest first.

No activity yet. Be the first.

Mask Style

Partial keeps the first and last 2 characters visible, handy for telling two redacted values apart without exposing either one.

Detect known key/token formats

Also catches AWS access keys, GitHub/Slack/Stripe tokens, JWTs, PEM private key blocks, and passwords embedded in database connection URLs, even if the variable name itself does not look sensitive.

Sensitive Key Patterns

A variable name is treated as sensitive if it contains any of these (case-insensitive, one per line). Add your own, e.g. a company-specific key name.

Comments (0)

Found this tool useful? Leave a comment, share a tip, or tell us how we can make it better.

No comments yet. Be the first to share your thoughts!

What this tool does

Secrets/Config Redactor takes a .env file, a YAML or JSON config, or any pasted text, and automatically masks the values next to sensitive-looking variable names (and well-known secret formats like AWS keys or GitHub tokens, wherever they appear) so the result is safe to paste into a chat AI, attach to a bug report, or post in a support channel.

How It Works

Every line is checked against a pattern that understands .env (KEY=value), YAML (key: value), JSON ("key": "value"), shell exports, and properties-style (key = value) syntax. The variable name is normalized (lowercased, punctuation stripped) and compared against the sensitive-keyword list; if it matches and the value is not empty, the value is replaced with a mask and the surrounding quotes, separator, and formatting are preserved exactly.

Before that line-by-line pass, an optional format-detection pass scans the entire pasted text for the literal shape of known secrets -- AWS access keys always start with AKIA, GitHub tokens start with ghp_/gho_/ghu_/ghs_/ghr_ or github_pat_, Slack tokens start with xoxb-/xoxp-/etc., Stripe keys start with sk_live_/sk_test_, JWTs are three base64url segments separated by dots, and PEM private keys are matched as a whole block from -----BEGIN to -----END. A database URL like postgres://user:password@host also has just its password segment masked, leaving the username and host visible since those are rarely sensitive on their own.

Problems it solves

Pasting a config file into a chat AI to debug it, without handing over real API keys and passwords in the process.
Attaching a .env or log snippet to a public bug report, GitHub issue, or support ticket safely.
Sharing your screen or a config file with a coworker during a call without scrambling to hide secrets first.
Double-checking a file for secrets you forgot were in there before committing it or sending it anywhere.

Frequently asked questions

›Is it actually safe to paste a real .env file into this?

Yes, in the sense that nothing you paste ever leaves your browser -- there is no server-side component to this tool at all, it is plain JavaScript running on the page you are looking at right now. That said, this tool is pattern-based, not perfect: always glance over the result before pasting it somewhere, especially for an unusual key name it might not recognize.

›How does it decide what counts as "sensitive"?

Two independent checks run together: variable names are matched against a list of sensitive keywords (password, secret, token, key, auth, credential, and more, listed and editable in the sidebar), and separately, the text is scanned for the actual shape of well-known secrets (AWS access keys, GitHub/Slack/Stripe tokens, JWTs, PEM private key blocks, and passwords embedded in database connection URLs) regardless of what the variable is called.

›Why does it sometimes mask things that are not actually secret, like AUTH_ENABLED=true?

Because "auth" is in the sensitive-keyword list and the tool deliberately errs on the side of over-masking rather than risking a missed secret. If this happens often for your config style, remove that keyword from the Sensitive Key Patterns list in the sidebar, or add your own more specific ones.

›What is the difference between Full and Partial masking?

Full replaces a value with a fixed-length "••••••••" no matter how long the original was, so the redacted result does not even leak the secret's length. Partial keeps the first and last two characters visible (e.g. sk••••••12), which is useful when you need to tell two different redacted keys apart in a bug report without exposing either one.

›Can I add my own sensitive key names?

Yes -- the Sensitive Key Patterns box in the sidebar is a plain editable list, one pattern per line. Add a company-specific variable name (like INTERNAL_SIGNING_SEED) and it will be masked on every line that contains it, matched case-insensitively regardless of underscores, dashes, or camelCase.