Free credential pattern detector
Paste any text — code, logs, .env files, paste-bin dumps, error reports — and the page scans for 50+ known credential patterns from the public TruffleHog and gitleaks rule sets. AWS access keys, GitHub PATs (classic + fine-grained), Stripe live/test keys, Slack tokens (bot/user/app), Discord bot tokens, OpenAI / Anthropic / HuggingFace keys, GCP API keys, Azure connection strings, JWTs, PEM/OpenSSH private key blocks, npm tokens, PyPI tokens, and more.
For OSINT and incident-response work: when investigating a paste-bin dump, an open S3 bucket leak, a stealer-log sample, or a misconfigured developer log, this tool is faster than running a full CLI scan. Each finding is tagged with confidence — high (vendor-defined prefix, near-certain real credential), medium (strong format match), low (generic pattern with many false positives).
For repository-scale scanning use TruffleHog or gitleaks. For continuous monitoring of GitHub for leaked credentials use GitHub's own secret scanning (free for public repos) or third-party services like GitGuardian. For your own air-gapped environment, both TruffleHog and gitleaks ship as standalone Go binaries.
Frequently asked questions
Is this on par with TruffleHog or gitleaks?
It implements the same well-known regex patterns from those tools' public rule sets, so you'll catch the same vendor-prefixed tokens (AKIA, ghp_, sk_live_, xoxb-, etc.). What it lacks compared to those CLI tools: entropy-based generic-secret detection, full git-history scanning, vendor-API-validation (calling the actual service to confirm a token is live), and ML-based custom rules. For ad-hoc paste-and-check it's equivalent; for repository auditing use the CLI tools.
Why does it mask the middle of high-confidence finds?
Defensive design. If you accidentally pasted a real credential into a browser tool, having the full string visible in the DOM creates extra exposure surface (extensions, screenshot tools, screen-share). The display masks the middle of high-confidence finds so the result is interpretable but not directly usable. The full match is in the JavaScript variables until you reload or close the tab.
Should I paste real production credentials here?
No. This tool exists for two legitimate use cases: (1) auditing log files, error reports, or paste-bin content where credentials may have been accidentally exposed by others, and (2) double-checking that you've scrubbed credentials from something before sharing publicly. For checking whether a specific live credential is in your own systems, use the CLI tools mentioned above on your local repository.
Will it find every credential type?
No. The pattern set is comprehensive for major SaaS vendors (AWS, GCP, Azure, GitHub, GitLab, Stripe, Slack, Discord, OpenAI, etc.) but every bespoke API has its own format. The "Generic JWT" and "PEM Private Key" patterns catch many cases not covered by vendor-specific rules. For a custom system's key format, look at the system's key issuance docs and add a regex.
What's the legal context for using this?
You can scan any text you have legitimate access to — your own logs, your own code, paste-bins you're investigating in the course of authorized OSINT work, or content sent to you for review. You should NOT search for, collect, or aggregate credentials that don't belong to you. If you find a credential exposed in someone else's public infrastructure, the right move is responsible disclosure to the affected vendor, not collection.