Secret Scanner
Paste code, a config file, a .env, a diff or log output and spot leaked secrets — AWS keys, GitHub and Stripe tokens, OpenAI / Anthropic / Google API keys, Slack, SendGrid and Twilio keys, private key blocks, JWTs and hard-coded high-entropy credentials. Each hit is masked, graded by severity and paired with how to rotate it safely. Everything runs in your browser; nothing is uploaded.
Runs 100% locally — nothing is uploaded. Your pasted text is scanned with regular expressions in this browser tab. It is never sent to a server, logged or stored. Safe for real config, .env files and logs.
What this tool is
- A free, in-browser secret scanner: paste code, a config file, a .env, a diff or log output and it flags values that look like leaked credentials.
- Detects AWS access keys and secret keys, GitHub / Stripe / Slack / SendGrid / Twilio tokens, OpenAI, Anthropic and Google API keys, PEM private key blocks, JWTs, and generic high-entropy api_key / secret / password / token assignments.
- Every finding shows the credential type, the line number, a masked preview (the full secret is never echoed), a severity grade, and specific remediation.
- A Shannon-entropy check on the generic rule suppresses obvious non-secrets like password = "password" or placeholder values, cutting false positives.
- Runs 100% client-side — the pasted text is parsed with regular expressions in your browser and is never uploaded, logged or stored anywhere.
Why leaked secrets are a top breach cause
A hard-coded API key, database password or private key is a credential an attacker can use directly — no exploit required. They end up in the wrong place constantly: committed to a repository, pasted into a chat or ticket, printed into a log, baked into a client bundle, or left in a .env that gets shared. Automated scanners crawl public code and new commits within seconds of a push, so a key that touches a public repo should be considered compromised the moment it lands. This tool is a fast, private first pass: paste the suspect text and see what matches a known credential shape before it goes anywhere it should not.
How detection works
- Format signatures. Most provider keys carry a fixed prefix and length —
AKIA…,ghp_…,sk_live_…,sk-ant-…,AIza…. These match with high confidence and almost never false-positive. - Contextual matches. Some secrets have no distinctive shape — an AWS secret access key is just 40 base64 characters. Those are only flagged when they appear next to a tell-tale key name, which keeps random base64 blobs from being reported.
- Entropy heuristics. For generic
api_key = "…"style assignments, the value's Shannon entropy and character-class mix must clear a threshold. High randomness looks like a real secret; a dictionary word or placeholder does not, so it is skipped. - Structural parsing. JWTs are matched by their three base64url segments, and private keys by their PEM
-----BEGIN … PRIVATE KEY-----header.
Severity grades
Findings are graded so you can triage. Critical covers live secrets that grant direct access or move money — AWS secret keys, Stripe live keys, GitHub tokens, model-provider keys and private key blocks. High covers bearer tokens and keys that are still sensitive but often scoped or short-lived — JWTs, Slack, SendGrid, Twilio, Google and AWS access key IDs. Medium is the generic high-entropy assignment: likely a secret, worth confirming by eye.
Rotate in the safe order — verify before you revoke
The single most common way a credential rotation goes wrong is revoking the old secret before the new one is confirmed working. Do it in this order every time:
- Generate the new credential.
- Verify it works with a real authenticated call.
- Swap every consumer — services, CI, local environments — over to the new value.
- Only then revoke the old credential.
If the secret reached git: rotating is necessary but not sufficient — the value stays in the commit history and is readable by anyone with repo access until you purge it (and even then, assume it was already harvested). Treat any key that touched a shared or public repository as compromised, rotate it, and check the provider's audit log for activity you did not perform. A secret is not a defence in depth control; it offers no protection once exposed.
Frequently asked questions
Does the Secret Scanner send my code anywhere?
No. The entire scan runs in your browser using JavaScript regular expressions. Nothing you paste is uploaded to a server, written to a database, or logged — it exists only in the current browser tab and is discarded when you clear the input or close the page. That is specifically why it is safe to paste a real .env file, a production config or a log line: the sensitive text never leaves your machine.
What kinds of secrets does it detect?
It matches well-known credential formats: AWS access key IDs (AKIA/ASIA) and contextual 40-character AWS secret access keys; GitHub tokens (ghp_, gho_, ghs_, ghr_, github_pat_); Stripe secret and restricted keys (sk_live_, sk_test_, rk_live_); OpenAI keys (sk-... and sk-proj-); Anthropic keys (sk-ant-); Google API keys (AIza...); Slack tokens (xoxb/xoxp/xoxa/xoxr/xoxs-); SendGrid (SG.) and Twilio (SK...) keys; PEM private key blocks (-----BEGIN ... PRIVATE KEY-----); and JSON Web Tokens (eyJ... header.payload.signature). It also catches generic hard-coded assignments to api_key, secret, password or token variables when the value has enough entropy to look real.
Why does it mask the secrets instead of showing them?
Showing a full secret in the results would re-expose it — in a screenshot, a shared screen, or a copied report. The scanner reveals only a short prefix and the last couple of characters (enough to locate the value in your file) and replaces the middle with bullets. The "copy report" button copies the masked findings only, so you can share where a leak is without leaking it again.
What is the entropy check for?
Generic rules that look for api_key = "..." or password: "..." would otherwise flag harmless examples such as password = "password" or token = "changeme". The scanner computes the Shannon entropy (randomness per character) of each generic candidate and requires a minimum level, plus a mix of character classes, before reporting it. Real credentials are high-entropy; dictionary words and placeholders are not. Format-specific detectors (AWS, Stripe, GitHub, and so on) do not need this because their shape is already distinctive.
I found a leaked key — what should I do?
Rotate it, and rotate it in the safe order. Generate the new credential first, verify it actually works with a real authenticated call, switch every consumer over to the new value, and only then revoke the old one. Revoking before the replacement is proven is how teams lock themselves out. If the secret was committed to git, also purge it from history (it stays in old commits otherwise) and review the provider's audit log for any use you did not make — a leaked key should be treated as already used.