Secret & API Key Scanner
Paste logs or config files to detect leaked credentials — AWS keys, GitHub and GitLab tokens, Stripe, Slack, OpenAI, JWTs and private keys. Scans locally.
Scan text
How it works
- Every line is scanned against a library of known credential patterns:
AKIA…for AWS access keys,ghp_…/github_pat_…for GitHub,glpat-…for GitLab,sk_live_…/sk_test_…for Stripe,sk-…for OpenAI,AIza…for Google,xox*for Slack, PEM private-key blocks, andeyJ…JWTs. - Secrets without a fixed prefix — like AWS secret access keys — are caught with a context heuristic: a long base64 token near the words aws or secret.
- Optionally, generic high-entropy tokens are flagged with Shannon entropy: random-looking strings score high, while words and sentences score low and are ignored.
- Everything runs in your browser as a plain regex scan. Nothing is uploaded, logged, or stored.
About Secret & API Key Scanner
Leaked credentials are one of the most common ways accounts get compromised: a developer pastes a config file into a chat, a build log prints an environment variable, or a support ticket includes an API key. This scanner helps you find those patterns before you share them — the redact feature rewrites every detected secret as [REDACTED:Label] so you can share sanitized logs safely.
Pattern matching is a strong first pass but not proof: a 40-character base64 string near the word aws is usually a secret access key but can be a false positive, and a real credential with an unknown format will not be flagged at all. Treat every finding as a potential leak, rotate any key you are not 100% sure about, and scan your repositories and chat history with a dedicated tool as part of your incident-response workflow.
Pattern matching, not understanding
The scan is a list of anchored regular expressions over the text you pasted: `AKIA` plus 16 uppercase characters for AWS access key IDs, `ghp_` and `github_pat_` for GitHub, `glpat-` for GitLab, `sk_live_` and `sk_test_` for Stripe, `sk-` for OpenAI, `AIza` for Google, `xox[baprs]-` for Slack, PEM private key blocks up to 4,000 characters, and JWTs shaped like three dot-separated base64url segments starting `eyJ`. These prefixes are vendor-issued and stable over time, which is precisely what makes them reliable regex targets.
AWS secret access keys carry no prefix, so they get a contextual rule: a 40-character base64-ish token with non-alphanumeric characters on both sides, appearing within 160 characters of the words *aws*, *secret access* or *access key*. The optional high-entropy pass adds generic detection — hex runs of 32+ characters scoring at least 3.5 bits per character, base64-ish runs of 32+ scoring at least 4.0 — but only for candidates whose boundaries are alphanumeric-delimited.
How to read the output
Overlapping hits are resolved by taking the longest match at each offset, so a JWT containing a long base64 blob reports one finding rather than three fragments of the same secret. Redaction rewrites each match to `[REDACTED:Label]` by splicing from the end of the string backwards, which keeps all earlier offsets valid as the text shrinks — the reason that direction matters, since replacing front to back would invalidate every position after the first edit.
Findings are listed with line and column numbers so you can jump to the source. The mask checkbox affects only the display — clicking any row copies the complete, unmasked secret to your clipboard regardless, and that is how you confirm a finding is real. Treat the findings list as sensitive as the text you pasted, and be deliberate about clicking rows in anything you then paste elsewhere.
Limits, and the order to respond in
False negatives are the larger risk. A credential whose format none of the patterns know will not be flagged, and neither will one that has been encrypted, base64-encoded twice, split across lines, or replaced by an indirection like `${{ secrets.API_KEY }}` — the reference is a secret dependency, not a leak. The entropy pass cannot close this gap either, since many real credentials are low-entropy strings while most high-entropy hex in a config file is an innocuous content hash.
When something real turns up, rotate and revoke it first, then read the provider's audit log to see whether it was used and by whom, then purge it from git history and CI logs, and only afterwards fix the pipeline that exposed it. Rotation comes first because every hour you wait is an hour the credential stays live, and rewriting history afterwards does not un-leak a key that was already cloned.
Frequently Asked Questions
How do I scan for exposed secrets in my code?
What types of secrets are detected?
Is my data sent to a server?
Do I need an account or API key?
Can I use these tools offline?
All processing happens in your browser. No uploads, no tracking, no servers. Your API keys, configs, and private payloads stay private — 100% client-side.