Secret / API Key Scanner
Paste code or a config file and find hardcoded API keys, tokens, and credentials before they reach git
About this tool
The Secret / API Key Scanner checks pasted code or config for the patterns real secrets actually have — an AWS Access Key ID always starts with AKIA followed by 16 characters, a GitHub token starts with ghp_, a Stripe secret key starts with sk_live_ or sk_test_. This is the same core approach tools like Gitleaks and TruffleHog lead with: a curated list of format-based rules, not a guess. It deliberately does NOT flag Stripe's pk_live_/pk_test_ publishable keys — those are designed to be public and embedded in client-side code, so treating them as a leak would be a false alarm. A lower-confidence rule also catches secret-sounding variable names (password, apiKey, token) assigned a literal string, for formats the specific rules don't cover. This is a format-based scanner, not a full secrets-detection pipeline — it can't confirm a matched string is a currently valid credential (that would require a live API call), and it can't catch a format it has no rule for. Use it as a fast first pass before a commit, not a replacement for a real scanning tool wired into your CI pipeline.
When to use it
- →Checking a file or diff for hardcoded credentials before committing
- →Reviewing a config file you're about to paste into a shared ticket or chat
- →Learning what real AWS keys, GitHub tokens, and Stripe keys actually look like
- →A quick sanity check before pushing a branch, without installing a CLI scanner
Tips
- ◆A clean scan here doesn't guarantee a file has no secrets — it only means none matched a known format or secret-sounding variable pattern. It can still miss an unusual or custom token format.
- ◆If this tool finds something real, the fix isn't just deleting the line — a secret committed to git exists in that commit's history forever. Rotate the credential at its provider first; that's the step that actually neutralizes the leak.
- ◆Stripe's pk_live_/pk_test_ keys are intentionally public-facing and are never flagged here — only sk_/rk_ (secret/restricted) keys are treated as real credentials.
Frequently asked questions
Does this scanner send anything I paste to a server?
No — all pattern matching happens with plain JavaScript regular expressions in your browser. Nothing you paste is ever sent anywhere, which also means it never validates whether a matched key is actually still active.
Why does it flag some things as 'possible' secrets with lower confidence?
The generic rule (a secret-sounding variable name assigned a quoted literal string) can't distinguish a real credential from a placeholder, a test fixture, or a non-secret config value that happens to be named similarly — it's a best-effort catch-all for formats the specific, high-confidence rules don't cover.
What should I do if I find a real secret in old code?
Rotate or revoke the credential at its provider immediately — that's what actually stops the leak. Then remove it from your current code, moving it to an environment variable or a secrets manager. Deleting the line in a new commit alone leaves the secret fully recoverable from your git history.