Scan a file for secrets
Runs locally in your browser. Your file never leaves your device.
By processing a file or pasted text here, you agree to the Terms.
Drop a file here to scan it — or
Logs, configs, .env files, source, JSON — any text file, up to 20 MB. A large file can pause this tab for a few seconds while it is scanned; nothing is uploaded, and nothing you drop in is changed.
…or paste text instead
Want these removed, not just flagged? Run the file through the log file redactor or the paste scrubber to get a copy with the secrets replaced by placeholders.
| Line | Category | Masked preview |
|---|
Your file, with any findings marked
Check a file for secrets before it leaves your machine
The moment before you paste a config into a chat, attach a log to a
ticket, or run git commit on a file you only half remember
writing, one question matters: is there a live credential in here? An API
key, a database password, a token that still works — the kind of thing
that turns a helpful bug report into an incident. This page answers that
question in your browser, without changing the file and without sending
it anywhere. It is a check, not a cleaner: it reads the file, tells you
what a pattern-based scan noticed, shows you exactly where, and leaves
every decision — and the file itself — with you.
What this scan looks for
Two layers, the same engine that powers this site’s
log file redactor. First, known
secret shapes: emails, IPv4/IPv6 addresses, JWTs, AWS access keys and
secret keys, Bearer and Basic auth tokens, and passwords or secrets
written as key=value. Those are reported as confident
findings. Second, an entropy pass: any long, random-looking run that
matches none of those patterns — a hex digest, a base64 blob, an
unfamiliar-looking token — is flagged as “possible secret — review”.
High-entropy strings are surfaced, never confirmed, because a random
string can be a session key or an innocent checksum and the tool has no
way to know which; that call is yours. Everything is reported with a
line number and a masked preview, so the report points at the problem
without ever printing the secret in full.
Why there is no “is this key live?” check
Some scanners go a step further and test whether a key they find is
still active — calling the provider that issued it to see if it
authenticates. That is genuinely useful, and this tool deliberately
does not do it, because it cannot do it honestly. Every page on this
site ships a Content-Security-Policy of connect-src 'none',
which tells your browser to refuse every outbound request this page
might try to make. That single rule is the whole trust story — it is
why your file provably never leaves the tab — and it is, by the same
stroke, why live verification is off the table: you cannot call a
provider to test a key from a page that is forbidden to call anyone.
You can confirm the rule yourself: open DevTools, watch the Network
tab, and scan a file — nothing goes out. We would rather be a tool that
can’t phone home than one that quietly ships your keys off to check
them.
This scanner vs. detect-secrets and CI gates
Repository-oriented secret scanners are built around a baseline: you install the tool, audit the whole codebase once, record the findings you’ve reviewed and accepted, and then gate every future commit against anything new. That workflow is the right one for a project with CI and a history to protect, and it is a different job from this one. This page is a one-shot, no-install check of a single file, right now, in a browser tab — the file you’re about to share this minute, not the repo you maintain over months. It keeps no baseline and blocks nothing; it simply reports what it sees so you can decide before you hit send. The two approaches are complements, not competitors: use a baseline scanner in your pipeline, and use this when a stray file is headed somewhere public and you just want to look before it goes.
When to use this vs. the redaction tools
Reach for this scanner when you only need to know — a fast answer to “is there a secret in this file?” that leaves the file untouched. Reach for a redactor when you need a clean copy to hand over: the log file redactor and the paste scrubber take the same input and return a version with the secrets replaced by consistent placeholders, ready to share. A natural flow is to scan first, and if the answer isn’t “nothing”, send the file through a redactor — the findings state above links straight to both.
What it can miss — read this before you share
Detection is pattern-based and best-effort — a clean report is not a guarantee the file is safe.
Detection is pattern-based and incomplete by construction; any scanner that implies otherwise is overpromising. The concrete gaps: a credential under an unfamiliar name or in a format the patterns don’t recognize is only caught if it happens to look random enough for the entropy pass, and random tokens shorter than about 20 characters stay below that statistical floor. Prose-shaped passwords are invisible to it. A secret split across lines, encoded, or wrapped in a structure the scan doesn’t understand can slip through. So a report of zero findings means “nothing matched the known shapes”, not “this file is safe to share” — the difference matters, and it is why the tool shows you your own file with what it found marked, rather than handing back a reassuring number. The final review is yours; this just makes it faster.
Practical limits
Files are scanned entirely in this tab’s memory with a 20 MB ceiling. The scan runs on the page’s main thread, so a large file can pause the tab for a few seconds — nothing is being uploaded during that pause; there is no network activity at all, which you can verify in DevTools. The file is only read, never modified: this tool has nothing to download because it changes nothing. The page works offline once loaded, and nothing persists after the tab closes.
Frequently asked questions
What does this scan look for?
The same categories the rest of this site’s tools redact: emails, IPv4/IPv6 addresses, JWTs, AWS access keys and secret keys, Bearer/Basic auth tokens, and passwords or secrets written as key=value. On top of those known shapes, any long, random-looking string that matches no pattern — a hex digest, a base64 blob, an unfamiliar token — is flagged separately as “possible secret — review”, because a high-entropy string can be a live credential or just a checksum and only you can tell the two apart. Every one of those is reported with its line number and a masked preview; nothing is decided for you.
Does this page upload my file, or check whether a key is still live?
No to both, and the second one is on purpose. This is a static page with no server behind it, and its Content-Security-Policy is set to connect-src ‘none’ — the browser itself refuses to let the page make any network request, which you can watch in the DevTools Network tab. That same rule is why this tool cannot tell you whether a key it found is still active: verifying a key means calling the provider that issued it, and calling anyone is exactly what connect-src ‘none’ forbids. Live verification is a real feature of server-side scanners; it is a confidence level a genuinely local tool cannot offer, and we would rather say so than quietly send your keys somewhere to test them.
Is the findings report safe to paste into a ticket?
Yes, by construction. Every value the scan reports — in the table, in the marked-up view of your file, and in the text you get from “Copy report” — is masked to its first few characters, an ellipsis, and its length, like AKIA…(20 chars). The full secret is never rendered anywhere on the page, so a screenshot or a pasted report can’t leak it. That is a deliberate design rule: a scanner that prints your secret back at you in full is its own liability.
How is this different from detect-secrets, gitleaks, or a pre-commit hook?
Those are built for a repository over time: you install a tool, audit the whole repo, accept a baseline of known-and-allowed findings, and then gate future commits against new ones. That baseline workflow is the right shape for a codebase with CI. This page is the other shape: a one-shot, no-install check of a single file you are about to paste into a chat, attach to a ticket, or share with a colleague — right now, in a browser tab, before it leaves your machine. It keeps no baseline and gates nothing; it just tells you what it sees so you can decide.
Should I use this or one of the redaction tools?
Use this when you only want to know — a fast check that answers “is there a key in here?” without touching the file. Use a redaction tool when you want a clean copy to share: the log file redactor and the paste scrubber take the same file and hand back a version with the secrets replaced by placeholders. A common flow is to scan first to see what’s there, then send the file through a redactor if the answer isn’t “nothing”.
Can it miss secrets?
Yes — detection is pattern-based and incomplete by construction, and no scanner can promise otherwise. A credential under an unfamiliar name, a secret in a format the patterns don’t know, or a short random token that stays below the entropy flagger’s statistical floor (roughly 20 characters) can all pass unnoticed. A clean report here means “nothing matched”, not “this file is safe” — treat it as a first pass that makes your own review faster, never as a guarantee. That is exactly why the tool shows you your file with what it did find marked, instead of just printing a number.