Secret and API key redactor

About this tool

Pasting a log into a GitHub issue, a Slack thread or a support ticket is one of the most common ways a real secret ends up somewhere it shouldn't. This scans pasted text against 14 recognisable secret shapes — vendor-specific prefixes like AKIA, ghp_, sk_live_ and xoxb-, plus a generic PEM private-key block — and replaces each match with a labelled placeholder before you copy the result out.

How it works

Each secret type is matched by its own regular expression, run entirely client-side. Where a vendor gives a token an identifiable prefix — AWS's AKIA/ASIA, GitHub's ghp_ and github_pat_, Stripe's sk_/rk_, Slack's xox*- and xapp-, npm's npm_, PyPI's pypi-, SendGrid's SG., Twilio's AC account SID, Shopify's shpat_/shpca_/shpss_, and Google's AIza — that prefix plus the documented length is what's matched. A PEM -----BEGIN PRIVATE KEY----- block and a JWT's three dot-separated segments are matched by shape alone. Overlapping matches are resolved by keeping the earliest, longest one, so a single string is never double-counted.

Common questions

Why wasn't my secret caught?

Only the 14 shapes listed under Known limitations below are matched. A secret with no recognisable vendor prefix — a bare API key, a database password, a random internal token — looks like ordinary text to a prefix-based scanner and will not be redacted. Read the pasted text yourself before posting it; this tool catches the common, recognisable cases, not everything.

Why is my Stripe publishable key still showing?

Stripe's own documentation states that publishable keys (pk_test_/pk_live_) are designed to be used in client-side code and are safe to expose — only secret keys (sk_) and restricted keys (rk_) are matched here.

Is a JWT actually a secret?

Not always — a JWT is a signed, not encrypted, token, and plenty are designed to be readable. It's flagged anyway because a JWT often carries session or identity data worth keeping out of a public paste, but check what it decodes to before deciding whether it needs redacting. This site's own JWT decoder reads one without sending it anywhere.

Known limitations

• 14 shapes onlyAWS access key ID, GitHub personal access token and fine-grained token, Google API key, Stripe secret/restricted key, Slack token and incoming webhook, npm token, PyPI token, SendGrid key, Twilio Account SID, Shopify access token, JWT, and a PEM private-key block. Anything else is not caught — see "Why wasn't my secret caught?" above.
• No AWS secret access key matchingUnlike the AWS access key ID, the paired secret access key has no distinguishing prefix — it's an unremarkable 40-character string. Matching it reliably needs entropy analysis and surrounding keyword context, which this tool doesn't attempt, rather than flagging huge numbers of ordinary hashes and tokens as false positives.
• Not a substitute for a real secret scannerTools like gitleaks or TruffleHog run hundreds of rules with entropy checks and are built to run in CI against your actual repository history. This page is a quick pre-publish check on one paste, not a replacement.

The same job at the command line

• gitleaks detectScans a git repository's full history against a much larger, entropy-aware rule set — the right tool before something is committed, not just before it's pasted.
• git diff --staged | gitleaks protect --stagedChecks only what's about to be committed, as a pre-commit hook.
• trufflehog filesystem .An alternative scanner with a different rule set — worth running both if a repository's history has never been checked.