VoriTools

Secret and PII Scanner

Paste text or load a text file to review possible exposures. Pattern matches need investigation and do not establish whether a credential is active.

Runs locally in your browser
View category: Security & Cryptography (30)
Parsing and analysis run entirely in your browser. No data is uploaded or sent to an API.
Source to scan

Pattern matching helps find likely exposure. It cannot prove that a value is valid, active, or harmful.

Finding summary
  • No scan has been run yet.

Find exposed values before they reach a commit or ticket

Use this local scanner to surface likely credentials and personal data in a pasted snippet. It redacts evidence in the report; use redacted test data whenever possible.

How to scan a snippet

Paste the text or load a file and press Scan locally. Every match is listed with its line number and a redacted excerpt, and the four counters above the list summarise what was found. Nothing is uploaded: the scan runs in this browser.

The rules cover private key headers, AWS, GitHub, GitLab, Slack, npm, SendGrid, Google, OpenAI, Stripe and Azure credentials, JWTs, bearer tokens, database URLs that carry a password, keyword assignments such as PASSWORD=… or {"api_key": "…"}, e-mail addresses, IPv4 addresses and TODO or FIXME notes.

  1. Paste code, .env content, configuration or logs into the field, or choose a local file (.env, .txt, .log, .json, .yaml, .yml, .js, .ts, .php, .py, .java).
  2. Press Scan locally. Load example fills the field with a prepared snippet and scans it straight away.
  3. Read the four counters: potential secrets, personal data, review items and action items.
  4. Work through the list; each row shows the level, the line number, what matched, and an excerpt such as sk_l••••ced instead of the value itself.
  5. Use Copy report to take the findings into a ticket, then press Clear before the next scan.

What the rules catch, and what they cannot

What the rules catch, and what they cannot

The scanner looks for the shapes that leak most often: -----BEGIN … PRIVATE KEY----- headers (RSA, EC, OpenSSH and PGP), AWS access key IDs, GitHub, GitLab, Slack, npm and SendGrid tokens, Google API keys, Stripe live secret keys, Azure storage account keys, JWTs, bearer tokens, database URLs that carry a password, and KEY=VALUE lines whose name contains TOKEN, SECRET, PASSWORD or API_KEY — including JSON-quoted keys such as {"password": "…"}, .env lines and semicolon-separated connection strings.

It is a pattern matcher, not a validator. A match does not prove that a credential is live or that a file is safe: the key may already be revoked, and a secret that is base64-encoded, split across lines or assembled at runtime will not be recognised. Treat the report as a list of things to check, and keep a repository-wide scanner in CI.

Placeholders, private addresses and version numbers

Values that only stand in for a secret are left alone: your-key, example-token, ${API_KEY}, <your-key>, changeme, •••• and xxxx. A dotted quad that belongs to a version (version = "1.2.3.4", awscli==1.2.3.4) is not reported as an address either.

Only public IPv4 addresses count as personal data. Private, reserved and documentation ranges — 10/8, 172.16/12, 192.168/16, 169.254/16, 127/8, 192.0.2/24, 198.51.100/24 and 203.0.113/24 — still appear in the list, but as notes: a LAN address in a log is rarely the finding you were looking for.

Redaction, line numbers and the copied report

Evidence is cut down to the first four and last three characters (sk_l••••ced), so the report can be pasted into a ticket without repeating the secret. The full value never leaves the tab and is not stored.

Each finding keeps the line it came from; identical matches on one line are collapsed, while the same value on two lines is reported twice. Listing stops after 250 findings so that a very large log cannot freeze the page.

Recent tools: