Secrets Scanner Simulator

Free Secrets Scanner — Find Exposed API Keys in Your Own Code

This is a defensive tool. Its job is to help you find credentials you have accidentally committed, pasted, or left in a config file — before someone else finds them. Paste code, a configuration file, a log excerpt, or an environment file, and it scans against 51 built-in detection patterns covering cloud provider keys, payment and messaging API tokens, private keys, bearer and OAuth tokens, and database connection strings. Every finding comes back with a line and column number, the surrounding line for context, a severity rating, and step-by-step remediation guidance for that specific credential type.

The scan runs entirely in your browser. Your code is never uploaded, never logged, and never leaves your device — which is the only sane design for a tool whose entire input is, by definition, secrets. You can also drop in a file; the file is read locally by your browser and never transmitted.

A Leaked Credential Must Be Rotated, Not Deleted

This is the single most important thing on this page, and the mistake nearly everyone makes the first time.

When you discover a key committed to a repository, the instinct is to delete the line and push a fix. That accomplishes almost nothing. The key is still in your git history, retrievable by anyone with clone access via git log -p, git show, or a reflog entry. If the repository was ever public, ever mirrored, ever forked, or ever cloned into a CI runner, the key exists in copies you do not control and cannot reach. Even rewriting history with filter-repo or BFG does not help: forks retain their own objects, GitHub caches unreachable objects that stay accessible by commit SHA, and any clone taken before the rewrite is untouched.

Worse, exposure is usually not hypothetical. Automated scanners crawl public repositories continuously and pull new credentials within minutes of a push. Published research and provider incident reports consistently show credentials being used by third parties within a very short window of a public commit. By the time you notice, assume it has been harvested.

So the correct response, in order:

1. Rotate or revoke first. Issue a new credential and invalidate the old one at the provider. This is the only step that actually ends the exposure. Do it before cleaning up the code.
2. Check for use. Review provider logs — CloudTrail, Azure sign-in and activity logs, GCP audit logs, the Stripe dashboard, GitHub security log — for anything unexpected between the moment of exposure and the moment of revocation.
3. Then remove it from the code and move it to a secrets manager or an environment variable that is not committed.
4. Consider history rewriting a cleanup step, not a remediation. Useful for hygiene and for stopping the next person copying it. Not a substitute for rotation.
5. Close the hole. Add the file to .gitignore, add a pre-commit scanning hook, and check whether the same credential was reused elsewhere.

The remediation text attached to each finding in this tool follows that order deliberately — rotate at the provider, audit for unauthorised use, move to managed secret storage, then tighten scope and enable rotation policies.

How to Use the Scanner

1. Provide the text. Paste it, or upload a file — source, .env, YAML, JSON, Terraform, a log excerpt, a CI configuration.
2. Read the findings. Results are sorted critical first, then by line number. Each shows the pattern that matched, the category, the line and column, the surrounding line, and the remediation steps.
3. Filter. Narrow by category (Cloud, API Keys, Private Keys, Tokens, Database, Other), by severity, or by free-text search across findings.
4. Control masking. Matched values are masked by default — first four characters, then asterisks, then last four — so you can screenshot results without leaking the credential. Toggle it off when you need the full value to identify which key it is.
5. Triage false positives. Mark any finding as a false positive; it stays visible but is set aside from the count.
6. Export. Save the findings as TXT, CSV, or JSON for a ticket or an audit record.

You can also add custom patterns: give a name, a JavaScript regular expression, a category, a severity, a description, and remediation text. The regex is validated before it is accepted, so a malformed pattern reports an error instead of silently matching nothing. Custom patterns are useful for internal token formats that no generic scanner knows about — an internal service key with a company-specific prefix, for instance.

What the 51 Patterns Cover

Severity reflects blast radius rather than string length. An AWS access key pair is critical because it can provision infrastructure and read every bucket in the account. A Stripe test key is rated low — it moves no real money — but is still worth flagging, because its presence usually means the live key is handled the same way somewhere else. A Twilio account SID is medium: not a secret by itself, but a strong hint that the auth token is nearby.

Limits You Should Understand

This is a regex-based scanner over text you paste. That has real boundaries, and knowing them keeps you from over-trusting a clean result.

• It scans what you give it, not your repository. It does not walk git history. A clean scan of your current working file says nothing about what is in commit 400 from last year. For history, use a repository scanner such as gitleaks or trufflehog.
• High-entropy secrets with no distinctive format may be missed. Providers that issue random strings without a recognisable prefix are hard to detect by pattern alone.
• False positives happen. Test fixtures, documentation examples, and placeholder values match the same shapes as real keys. That is why triage and the false-positive toggle exist.
• A match is not proof the credential is live. Verify at the provider — but if you cannot immediately prove it is dead, rotate anyway. Rotation is cheap; an unrotated live key is not.

The durable fix is to stop secrets reaching version control in the first place: keep them in a secrets manager, inject them at runtime as environment variables, list the files in .gitignore before the first commit, and run a scanner as a pre-commit hook and in CI.

Frequently Asked Questions

Is my code uploaded when I scan it?

No. All 51 patterns are evaluated in your browser using JavaScript. Nothing is transmitted, stored, or logged. Uploaded files are read locally by the browser’s file reader and never sent anywhere.

I removed the key and pushed a fix. Am I safe?

No. The credential is still in git history and in every clone, fork, mirror, and CI cache that pulled the repository. Deleting the line stops nothing. Rotate the credential at the provider first — that is the only action that ends the exposure.

Does rewriting git history fix it?

Not by itself. Forks keep their own objects, hosting platforms can retain unreachable objects addressable by commit SHA, and any clone taken before the rewrite is unaffected. Treat history rewriting as cleanup after rotation, never instead of it.

How fast do exposed keys get abused?

Fast. Automated scanners monitor public repositories continuously and act on new credentials within minutes. Assume any key that reached a public repository has been harvested, and prioritise rotation over investigation.

What if the finding is a false positive?

Mark it as one. Test fixtures and documentation placeholders routinely match real key formats. If you are genuinely unsure whether a value is live, rotating it costs far less than being wrong.

Can I add patterns for our internal token format?

Yes. Add a custom pattern with your own regular expression, category, severity, and remediation text. The regex is validated when you add it, so an invalid pattern surfaces an error rather than silently matching nothing.

Why are matched values masked by default?

So the results page is safe to screenshot and share with a colleague or attach to a ticket. Masking shows the first four and last four characters, which is enough to identify which key it is without reproducing it. Toggle it off when you need the full value.

Does this replace gitleaks, trufflehog, or GitHub secret scanning?

No. Those walk full repository history and run automatically in CI; this is an interactive scanner for a file or snippet in front of you, useful for a quick check before committing, reviewing a pull request diff, or auditing a config someone sent you. Run both.

What should I do after a clean scan?

Add pre-commit scanning so the check happens automatically, generate a proper .env file for local configuration, and keep it out of version control with a .gitignore. Detection is a backstop; the goal is that secrets never enter the repository at all.