Runs entirely in your browser — nothing leaves this page.

Secret scanner

Check a config, .env, Dockerfile or manifest for accidentally committed credentials — AWS keys, GitHub tokens, private keys, JWTs — before they reach git.

Drop a config or .env file to scan it

scanned locally in your browser — the file is never uploaded

Or paste the text

Paste a config above or drop a file to scan for leaked credentials.

Catching credentials before git does

Paste a config, a .env file, a Dockerfile or a CI manifest — or drop the file — and it is scanned against the token formats of the providers that actually get leaked: AWS, GitHub, GitLab, Slack, Stripe, Google, OpenAI, npm, SendGrid, Twilio, Telegram, plus PEM private key blocks, JWTs, credentials embedded in URLs and generic high-entropy password assignments.

Everything runs in your browser — pasting a file full of secrets into a web page that uploads it somewhere would defeat the purpose, so this one doesn't. Matches are shown masked (first and last four characters) and obvious placeholders — env-substitutions, changeme and the like — are filtered out.

One rule matters more than the scanner: a secret that has ever been committed is burned. Rotate it. Deleting the line, amending the commit or force-pushing does not un-leak a value that CI logs, forks and clones have already seen.

Why did it flag a value that isn't secret?

The generic rule fires on password/secret/token assignments whose value looks random (high entropy). A generated non-secret ID can look the same. The provider-specific rules — AKIA…, ghp_…, sk_live_… — are near-certain, the generic ones are a prompt to look.

Can it miss real secrets?

Yes. A scanner sees formats, not intent: a password that is a dictionary word, or a provider whose tokens have no recognizable prefix, will pass. Treat a clean result as "nothing obvious", and keep secrets out of files with a manager or environment injection.

What should I do when it finds something in a repo?

Rotate the credential first — that is the fix. Then remove it from history if the repo is shared (git filter-repo), move the value to a secret store, and add a pre-commit scanner (gitleaks, trufflehog) so the next one never lands.

Why is a JWT only a warning?

Tokens expire — a JWT in a fixture or an example is often long dead. But an unexpired one is a live session, and refresh tokens live longer than you think, so each one deserves a look rather than an automatic alarm.