Secret & Credential Detector

What this scanner checks and how

Paste code, a config file, a shell script, or a .env and this tool runs it through a set of pattern matchers built for the credential formats that actually get committed by accident — cloud API keys, private keys, database URLs, webhooks and bot tokens — plus two more general checks: assignments to suspicious variable names, and a high-entropy heuristic as a last resort. Every hit is reported with a line number, a redacted version of the value (first and last four characters only — never the full secret), and what to actually do about it.

Cloud and platform API keys

AWS access key IDs (AKIA/ASIA followed by 16 uppercase characters), GitHub tokens (ghp_, gho_, github_pat_ and friends), Stripe, Google, OpenAI and Anthropic keys all have a fixed, documented prefix and length — that specificity is what makes them safe to match directly, without needing surrounding context. An AWS secret access key is different: it is just a 40-character string with no distinguishing prefix, so it is only flagged when it sits next to a variable name that says what it is (aws_secret_access_key, AWS_SECRET_ACCESS_KEY), which is how it appears in essentially every real leak.

Private keys and database connection strings

A PEM block (-----BEGIN RSA PRIVATE KEY----- and its EC, OpenSSH, PGP and DSA cousins) is treated as critical the moment the header appears — there is no legitimate reason for key material to be sitting in a code file or a chat log. Database connection strings are checked for the specific shape scheme://user:password@host; a connection string with no embedded password (increasingly common with IAM-based auth) is not flagged, because there is nothing to leak.

Generic assignments and the high-entropy heuristic

Not every secret has a recognisable prefix. A variable literally named password, secret, token, api_key or auth holding a quoted string is flagged as high severity — unless that string is an obvious placeholder (empty, changeme, xxx, <your-key-here>, ${API_KEY}, process.env.X, and similar). Getting that exclusion list right is most of what separates a useful scanner from one that flags every .env.example in your repository. As a final catch-all, any variable assigned a long (33+ character) base64- or hex-looking literal is flagged at low severity and explicitly labelled possible — it is common for a hash, a cache key or test fixture data to look exactly like this from the outside.

// Instead of this:
const stripeKey = "sk_live_51H8xX2yZ0aBcDeFgHiJkLmNoPqRsTuVwXyZ";

// load it from the environment (and keep .env out of git):
const stripeKey = process.env.STRIPE_SECRET_KEY;
if (!stripeKey) throw new Error('STRIPE_SECRET_KEY is not set');

Deleting the line does not delete the leak

Git is a history of every version of every file, not just the current one. Committing a secret, then deleting it in a later commit, does not remove it — anyone with clone access can check out the earlier commit, look at the diff, or simply run git log -p and read it straight out of history. Force- pushing a rewritten history helps only if every existing clone, fork and CI cache is also purged, which in practice is close to never guaranteed. The credential has to be treated as burned the moment it was committed, not the moment someone notices.

Rotate first, then remove

Removing the line from source fixes the code; it does nothing about every place the old value is still valid — the provider’s systems have no idea you deleted a line from a file. Rotating the credential (issuing a new one and revoking the old one at the provider) is the step that actually closes the exposure, and it is the step people skip because it feels like the smaller, less urgent task compared to fixing the code. Do it in this order: rotate first, confirm the old credential is dead, then clean up the source and the history.

Why this runs entirely in your browser

A tool that asks you to paste API keys and then sends them to a server is asking you to trust that server with exactly the thing you are trying to protect — a strange position for a security tool to put you in, and unnecessary here. Every check this page runs is plain string and regular-expression matching, which JavaScript can do natively in your tab. There is nothing about detecting the shape of an AWS key or a private key header that requires a network round trip, so there isn’t one. You can verify this yourself: open your browser’s network tab, paste something in, and watch nothing happen.

The first ten minutes after you find a leaked production key

Rotate it first — issue a replacement credential and revoke the old one at the provider (IAM, the GitHub token settings page, the Stripe dashboard, wherever it lives) before doing anything else. Then check the provider’s access or audit logs for activity on that key since it was exposed — API calls, logins, or resource creation you don’t recognise. Update every place the old value was actually in use so nothing breaks silently once it’s revoked. Only after the credential is dead and replaced should you go back and clean up the source — remove the line, and if it was ever pushed to a shared or public repository, treat the git history as compromised too, not just the current file.