Secret Redactor
A secret redactor scans text you are about to share — a log excerpt, a support ticket, a chat message, a config dump — and removes the credentials hiding inside it before anyone else reads them. Paste text or drop a file here and it finds provider API keys, access tokens, private-key blocks, JSON Web Tokens, card numbers and email addresses, shows each hit masked in a table, and builds a clean copy with every secret replaced by [REDACTED]. Everything runs 100% in your browser: nothing is uploaded, nothing is stored, and analysing text makes no network request. The companion guide, redact secrets before you paste, explains what scanners can and cannot catch; for browser captures use the HAR Analyzer, and for configuration files the .env Parser.
Last updated:
Or drop a text file anywhere in this box. Limit: 2 MB. The file is read on this device only and is never uploaded.
Scan results
Highlighted preview (masked)
Findings
What the scanner looks for — and how it decides
Most secrets do not leak through attacks; they leak through helpfulness. Someone pastes a log into a ticket, a config file into a chat, a curl command into a forum post — and the credential that happened to be inside travels with it, into systems that index, forward and archive text forever. This page is the pause before that paste. Type or drop the text and the scan runs as you type: a counts band totals the findings by type, the preview highlights each hit in place with its value masked, the findings table lists the type, the masked form and the line number, and the redacted copy below replaces every hit with the single marker [REDACTED], ready to copy or download as a .txt file.
The first layer of detection is shape. Real credentials from real providers have recognisable shapes, and the scanner knows the main ones: AWS access keys, GitHub tokens in both classic and fine-grained form, Stripe secret and restricted keys, OpenAI project and generic keys, Anthropic keys, Google API keys and Slack tokens. A private-key block is caught as one whole hit from its BEGIN line to its END line, because redacting only part of a key block still leaves a usable key. JSON Web Tokens are recognised by their three base64url segments, and card numbers must pass the Luhn checksum before they are flagged, so ordinary order numbers and timestamps stay quiet.
Entropy, placeholders and the honest limits
The second layer covers secrets that carry no provider shape: assignments such as password = …, api_key: … or client_secret = …. A bare keyword proves nothing, so the value must clear two more gates — at least twelve characters, and a Shannon entropy of at least 3.2 bits per character, which random keys pass easily and ordinary words fail. Placeholder values are excluded by design: anything containing example, test, dummy, xxx, your-, placeholder or changeme is documentation, not a credential, and flagging it would train you to ignore the scanner. Where shapes overlap, the specific pattern wins: a Stripe key assigned to a variable is reported once, as a Stripe key.
Two finding types protect people rather than systems. Email addresses are flagged as personal data, because a ticket full of customer addresses is a privacy incident even when no password appears. Card numbers are flagged only when the digits pass Luhn, the checksum built into every real card number — the same test that lets the scanner ignore invoice numbers, tracking codes and Unix timestamps that merely look long and numeric. On screen, every value is masked to at most its first four characters, so a shoulder-surfer or a screenshot learns the type and the location of a secret but never the secret itself; short values show nothing at all. The full value exists only in your original text, which never leaves the page.
Use the redactor as one step in a safer sharing habit, not as a guarantee. Redact locally, share the redacted copy, and send the actual secret — when a secret genuinely must change hands — through a secrets manager or an expiring share link, never through the same ticket or chat as the redacted text. If a real credential has already been pasted somewhere unredacted, deleting the message is not enough: copies, indexes and notifications may already exist, so rotate the credential and treat the old one as public. The companion article, redact secrets before you paste, works through that workflow in full; the HAR Analyzer does the same job for browser captures, and the .env Parser checks configuration files before you commit them.
The detection library, in plain terms
| AWS access key | AKIA or ASIA followed by exactly 16 uppercase letters or digits — the shape of long-term and temporary AWS access key IDs. |
| GitHub token | The ghp_, gho_, ghu_, ghs_ and ghr_ prefixes with at least 36 further characters, plus the fine-grained github_pat_ form. |
| Stripe key | sk_ or rk_ followed by live_ or test_ and at least 16 alphanumeric characters — secret and restricted keys, test mode included, because test keys reveal account structure and habits. |
| OpenAI and Anthropic keys | sk-proj- project keys and generic sk- keys of 32 or more characters count as OpenAI; sk-ant- keys are reported as Anthropic, a separate type with a separate rotation path. |
| Google API key and Slack token | AIza followed by 35 characters for Google; xoxb, xoxa, xoxp, xoxr and xoxs prefixes for Slack bot, app, user, refresh and session tokens. |
| Private key block | A whole PEM block, from -----BEGIN PRIVATE KEY----- (RSA, EC, OpenSSH and PGP variants included) through the matching END line, reported and redacted as a single hit. |
| JSON Web Token | Three base64url segments separated by dots, with the first two segments starting eyJ — the encoded form of the JSON header and payload every JWT begins with. |
| Generic assignment | Values assigned to names such as api_key, secret, token, password, passwd, auth_token, access_token or client_secret, flagged only when the value is at least 12 characters and its Shannon entropy reaches 3.2; documented placeholders never flag. |
| Email address | Ordinary email addresses, reported as personal data (PII) so bulk pastes of customer or staff addresses are caught before they spread. |
| Credit card number | Digit sequences of 13 to 19 digits, spaces and dashes allowed, flagged only when they pass the Luhn checksum every genuine card number satisfies. |
| Masking and the marker | On screen a value shows at most its first four characters plus an ellipsis, and nothing for values of four characters or fewer. In the redacted copy every hit becomes the single marker [REDACTED]; the type stays visible in the findings table, never inline. |
Frequently asked questions
Is my text uploaded or stored anywhere?
No. The scan runs in this page, on your device: nothing is uploaded, transmitted or stored, and scanning makes no network request. That is a deliberate design rule — a tool that asked you to upload text full of secrets in order to remove the secrets would be part of the problem.
What kinds of secrets can it find?
Provider-shaped credentials — AWS access keys, GitHub, Stripe, OpenAI, Anthropic, Google and Slack keys and tokens — plus whole private-key blocks, JSON Web Tokens, high-entropy values assigned to names like password or api_key, email addresses, and card numbers that pass the Luhn checksum. The facts table above lists every pattern in plain terms.
Why did it miss a secret I can see in my text?
Three honest reasons. The value may be split across lines or wrapped, so no single shape matches. It may be a low-entropy human password assigned to a name the generic rule does not know. Or it may be a format no pattern covers yet — a database connection string, a cookie value, a basic-auth URL. The scanner catches the common, well-documented shapes deterministically; it is a safety net, not a proof that text is clean, so skim the preview yourself before you share.
Why did it flag something that is not a real secret?
Usually because the value is honestly shaped like one: a random-looking test value with no placeholder wording, a sample token from internal documentation, or a JWT used as a front-end example. Check the findings table before you share — a false positive costs a glance, while a false negative costs a rotation. Values containing example, test, dummy, xxx, your-, placeholder or changeme are never flagged, so marking samples that way keeps the noise down.
Does redacting a secret make it safe if the original already leaked?
No. Redaction protects the copies you make from now on; it cannot recall a ticket, chat message or log that already went out with the secret in it. Treat any credential that has appeared unredacted in a shared system as public: rotate it at the provider, revoke the old one, and only then share the redacted text. The companion article, redact secrets before you paste, explains the rotate-first order and why deleting the message is not enough.