Search DevTools

Jump to any tool or page

Secret & Credential Scanner

Paste code, a .env file, or a config to find leaked API keys, tokens and credentials before you commit or share it. Everything runs locally in your browser — the input is never uploaded anywhere.

Input

0 chars
Scanned entirely on-device. Nothing you paste here leaves your browser.

Findings

0 findings

Paste code, a .env file, or a config to scan for secrets.

Developer Utilities

About Secret & Credential Scanner

Paste code, config or a diff to flag credentials before they reach a commit, using both provider-specific patterns and Shannon entropy on high-randomness strings. The uncomfortable truth about this class of bug is that detection is the easy half: once a key has been pushed, deleting the line fixes nothing, because git retains the blob and any clone or fork already has it.

Frequently asked questions

How does entropy detection differ from pattern matching, and why use both?
Pattern matching keys off known prefixes and shapes — AKIA followed by sixteen uppercase alphanumerics for an AWS access key ID, ghp_ for a GitHub personal access token, sk-ant- for an Anthropic key. It is precise but blind to anything unrecognised. Entropy scoring instead measures the character distribution of a candidate string: a base64 secret typically exceeds about 4.5 bits per character, hex about 3.0, whereas English prose sits near 2.5. Together they catch both known formats and bespoke credentials.
What causes false positives, and how do I reduce them?
Anything long and random-looking trips entropy: git SHAs, UUIDs, content hashes in lockfiles, minified bundles, base64-encoded images, CSS integrity attributes and test fixtures. Minified JavaScript is the worst offender because every mangled identifier looks like noise. Reduce noise by excluding lock files, dist directories and binary assets, by raising the entropy threshold for hex specifically, and by treating a match near an assignment to a variable named key, token, secret or password as far higher signal than a bare string.
I removed the key and force-pushed. Am I safe?
No. Assume the credential is compromised and rotate it. The old commit object survives in the local repository until garbage collection, on the remote in reflogs and in any pull request or fork, and in CI logs, caches and mirrors — GitHub in particular keeps dangling commits reachable by SHA on forks indefinitely. Automated scrapers pull the public events firehose and test new keys within minutes. Rotate first, then rewrite history with filter-repo or BFG if you must, then revoke the old value.
What does an entropy threshold actually trade off?
It trades recall against noise, and the right setting depends on the charset. A threshold near 4.5 bits per character over base64 catches most real 32-byte secrets while ignoring ordinary identifiers; drop to 3.5 and you will surface every UUID in the codebase. Short secrets are the hard case, since entropy is unreliable below roughly twenty characters — a sixteen-character password scores low regardless of quality. Pattern rules, not entropy, are what catch those.
Why do secrets end up in .env.local, and does that actually protect them?
Only if the ignore rule was in place before the first commit of that file. Adding a path to .gitignore has no effect on a file git is already tracking — it stays staged and keeps committing until you run git rm --cached. Two further leaks are common: environment variables prefixed for client exposure, such as NEXT_PUBLIC_, are inlined into the browser bundle at build time and are public by definition; and .env files are routinely copied into Docker images by a broad COPY . . instruction.