Secret Scanner for Prompts
Catch API keys, tokens, private keys and connection strings in text before you paste it into a chat window, a ticket or a prompt.
Everything on this page runs in your browser. Nothing is uploaded, logged or sent anywhere — and unlike the other pages in this family, what you paste here is deliberately NOT written into the URL. Only the settings are. A scanner that put your secrets in a shareable link would be causing the leak it exists to prevent.
Anything real in this list needs rotating, not deleting. A secret that has been in a clipboard is a secret that has left your control.
- Characters scanned
- 528
- Matched a known format
- 6
- Caught by entropy alone
- 0
- Highest entropy seen
- 5.36 bits/char
- Distinct formats
- 5
Findings
- checkAssignment to a secret-looking name — B•••••line 4, column 22
Basis: shape only. a variable whose NAME contains SECRET, TOKEN, PASSWORD, KEY, CREDENTIAL or AUTH, with a value assigned to it If this is a real credential, it has now been in a clipboard and possibly in a chat log. Rotate it — removing it from the text does not un-share it.
- must fixOpenAI-style key — sk-p••••••••••••••••••••••••••••••••••••••••4iO1line 4, column 29
Basis: known prefix. an `sk-` or `sk-proj-` prefix followed by a long token If this is a real credential, it has now been in a clipboard and possibly in a chat log. Rotate it — removing it from the text does not un-share it.
- must fixAWS access key ID — AKIA••••••••••••MPLEline 8, column 19
Basis: known prefix. AKIA/ASIA/AIDA/AROA plus sixteen uppercase base32 characters If this is a real credential, it has now been in a clipboard and possibly in a chat log. Rotate it — removing it from the text does not un-share it.
- must fixConnection string with a password — p••••••••••••••••••••••••••••@d•••••••••••••••line 9, column 14
Basis: verified. a URL whose userinfo section carries a password If this is a real credential, it has now been in a clipboard and possibly in a chat log. Rotate it — removing it from the text does not un-share it.
- checkAssignment to a secret-looking name — b7f3•••••••••••••••••••••••••04afline 10, column 16
Basis: shape only. a variable whose NAME contains SECRET, TOKEN, PASSWORD, KEY, CREDENTIAL or AUTH, with a value assigned to it If this is a real credential, it has now been in a clipboard and possibly in a chat log. Rotate it — removing it from the text does not un-share it.
- must fixJSON Web Token — eyJh••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••EjXkline 12, column 25
Basis: verified. three base64url segments whose first segment decodes to JSON containing `alg` If this is a real credential, it has now been in a clipboard and possibly in a chat log. Rotate it — removing it from the text does not un-share it.
Here's the failing request, can you see what's wrong?
curl https://api.example.com/v1/chat \
-H "Authorization: [REDACTED_ASSIGN] [REDACTED_OPENAI]" \
-H "Content-Type: application/json" \
-d '{"model":"m","messages":[]}'
AWS_ACCESS_KEY_ID=[REDACTED_AWS]
DATABASE_URL=[REDACTED_DSN]/prod
SESSION_SECRET=[REDACTED_ASSIGN]
The token it returns is [REDACTED_JWT]What each basis means
Verified: the format itself proves what it is. A PEM private-key header, a JWT whose first segment decodes to JSON containing alg, a URL with a password in its userinfo section. These are not guesses.
Known prefix: a documented vendor prefix and length. Strong, and not proof — the prefix is public, so an example string in documentation matches exactly as well as a live key does. Several vendors, GitHub among them, put a checksum in their tokens; this tool does not verify any of them, which is stated here rather than glossed over.
Shape or entropy only: a variable whose name suggests a secret, or a long mixed string with high per-character entropy. Weak by construction. A UUID, a git commit hash, a base64-encoded image, a minified bundle and a content hash all score highly and none of them is a credential.
Not detected: passwords that look like words, any key format not on the list, secrets split across lines or concatenated at runtime, and anything encrypted or encoded before it reached this text. A clean result here means these detectors did not match.
Rotate, do not delete
The instinct on finding a key in text you were about to paste is to remove it and carry on. That is the wrong half of the fix. If the key was in a file you shared, a screenshot, a ticket, a chat message or a repository — even briefly, even in a branch that was deleted — treat it as public and rotate it. Deleting the line changes what a future reader sees and nothing about who already has it, and git in particular keeps the old object around long after the commit that removed it stops being visible.
Why prompts specifically
Because the paths that leak keys into prompts do not look like the paths that leak them into code. Nobody commits a key deliberately, but people paste a failing curl command into a chat window a dozen times a week, and that command has an Authorization header in it. Error messages and stack traces carry connection strings. An agent asked to debug a service reads its own environment. And a few-shot example in a system prompt, written once from a real request, ships the key it was copied from to every model call your product makes, forever.
The threshold is a dial with a cost at both ends
There is no setting that finds every secret and nothing else, because "looks random" is not a property that distinguishes a key from a hash. Lower the threshold and every commit SHA and UUID in your logs becomes a finding, the list gets long, and people stop reading it — which is how scanners fail in practice. Raise it and hex-encoded secrets go first, because hexadecimal caps at 4 bits per character no matter how good the random source was. The known-format list is the part that actually works; the entropy scan is there to catch the thing that is not on it yet.