API Key and Secret Scanner
Before you paste logs, code or a .env file into ChatGPT, scan it: keys such as sk-proj-…, AKIA… (AWS), ghp_… (GitHub), AIza… (Google), xoxb-… (Slack), sk_live_… (Stripe), JWTs, PEM private keys and DB_PASSWORD=… values are highlighted and replaced with [REDACTED_…]. Random-looking strings of 24+ characters with at least 4.0 bits of Shannon entropy per character are flagged too. Nothing leaves your browser.
How to use
- Paste the log, code, config file or prompt you are about to send to an AI chat. Scanning starts as you type.
- Check the highlighted spots and the list with line numbers. Red marks are known key formats; blue marks are random-looking strings that may be secrets.
- Copy the redacted text. Tick "Keep the first 4 characters" if you want the reader to see which key it was, such as ghp_****.
How it works
Known providers are matched by their fixed prefixes and lengths: OpenAI sk- and sk-proj-, Anthropic sk-ant-, AWS access keys AKIA or ASIA plus 16 capital letters or digits, GitHub ghp_, gho_ and github_pat_, Google AIza plus 35 characters, Slack xoxb- and xoxp-, Stripe sk_live_, pk_live_ and rk_, JWTs (three base64url parts starting with eyJ) and -----BEGIN … PRIVATE KEY----- blocks.
Values are also caught by their name. In .env and config files, anything assigned to a name containing SECRET, TOKEN, PASSWORD, API_KEY, ACCESS_KEY or PRIVATE_KEY is masked, as are AWS secret keys (40 characters after aws_secret_access_key) and the password in connection strings such as postgres://user:password@host. Placeholders like changeme, <your-key>, ${VAR} and **** are ignored.
Strings without a known shape are scored with Shannon entropy: H = -sum p(c) log2 p(c) over the characters. A token of 24 or more characters that mixes upper case, lower case and digits and scores at least 4.0 bits per character is flagged. A random 32-character key usually scores 4.5 to 5. Pure hexadecimal strings such as commit hashes and UUIDs are skipped.
When two rules hit the same text, the more specific one wins: a key inside OPENAI_API_KEY=… is labelled OpenAI, not a generic .env secret. Everything runs on this page. The text is not uploaded, not saved and never written into the page address.
Formats it recognises
| Provider | Looks like |
|---|---|
| OpenAI | sk-… , sk-proj-… |
| Anthropic | sk-ant-… |
| AWS | AKIA… (20 characters) + 40-character secret |
| GitHub | ghp_… , github_pat_… |
| Google API | AIza… (39 characters) |
| Slack | xoxb-… , xoxp-… , hooks.slack.com URL |
| Stripe | sk_live_… , pk_live_… , rk_… |
| JWT | eyJ….eyJ….… |
| Private key | -----BEGIN … PRIVATE KEY----- |
| Connection string | scheme://user:password@host |
| .env value | NAME_WITH_SECRET/TOKEN/PASSWORD=… |
FAQ
Is my text sent anywhere?
No. Scanning and redaction run in your browser. The text is not uploaded, not stored in local storage and not added to the URL, so there is nothing to share by accident. Leaving the page clears the box.
I already pasted a key into ChatGPT. What now?
Rotate it. Revoke the key in the provider dashboard and create a new one, even if you deleted the chat. Chats can be kept for abuse review or used for training depending on your settings, and a key that was exposed once should be treated as leaked.
Why is a normal string marked as a secret?
The entropy check flags long, random-looking strings, and some harmless values look like that: build IDs, base64 images, signed URLs. Blue marks are guesses. Untick "Flag random-looking strings" to see only known key formats and named values.
What does it miss?
Short or human-made passwords written in a sentence, secrets with no name and low randomness, keys from providers with no fixed prefix, and values split across lines. Read the result before you send it. Scanning lowers the risk, it does not prove the text is clean.
Are the example keys real?
No. The sample uses AWS documentation example keys, the public jwt.io example token and made-up strings. They have the right shape but do not unlock anything.