b2KIT

Git Diff Secret Finder

Paste git diffs and detect leaked credentials, tokens, and secrets using pattern-matching rules.

Tested tool guide Tested browser tools Checked August 16, 2026

What Git Diff Secret Finder does and how it behaves

Git Diff Secret Finder screens pasted patch text for strings that resemble exposed credentials, access tokens, and other secrets. It applies pattern-matching rules to the exact diff you provide and returns candidates for human review before a patch is committed, posted, or attached to an issue. The important surprise is that a match is an alert, not proof that the value is genuine, active, or sensitive. Conversely, a scan with no findings is not proof that the patch is safe: unfamiliar formats, transformed values, and secrets outside the pasted diff can remain undetected. Read findings in the context of Git's added, removed, and unchanged lines.

How the result is produced

1

Patch-scoped pattern scan

Paste a textual Git diff, including its file headers, hunk markers, and changed lines. The finder treats that supplied patch as its search scope and compares its text with rules for secret-like formats. It does not infer missing content from a repository name or inspect files that were not pasted. Use the surrounding hunk and each line's prefix when deciding whether a candidate represents an addition, deletion, or context.

2

Local candidate handling

Processing occurs entirely in the browser, so this tool does not upload the pasted diff. That is especially relevant because the material being checked may already contain a live credential. Pattern matching measures textual resemblance only; the finder does not authenticate against an issuing service, test permissions, establish ownership, determine exposure, or decide whether a token has expired. Verification, rotation, and revocation must be handled outside the finder.

Good uses

  • Review a staged or pull-request diff for a configuration change before sending it to a remote repository, especially after temporary credentials were used during testing.
  • Check a patch copied from an incident ticket or chat before reposting it, where troubleshooting commands or headers may contain bearer tokens or credential assignments.
  • Scan a deployment diff that changes environment, infrastructure, or CI configuration, then inspect every reported candidate before approving the release.

Limits and checks

  • Matches are candidates, not validation. Placeholder tokens, documentation samples, hashes, UUIDs, and ordinary high-entropy identifiers can resemble credential material. Classification still depends on the file, line, provider format, and whether the value was intended to grant access.
  • No finding is not an assurance of safety. Custom formats, encoded values, values split across lines, short passwords, templated secrets, and credentials assembled at runtime may not resemble any rule closely enough. The result covers detectable patterns, not every way sensitive information can appear.
  • Only the pasted patch is in scope. Earlier commits, untracked files, ignored files, binary content not represented as text, and working-tree changes absent from that paste are not examined. A diff can also omit unchanged portions of a modified file, so this finder is not a repository-wide or full-file secret audit.

Common questions

Does a finding mean the credential is active?

No. A finding means only that the text matched a rule for a secret-like form. The finder does not contact an issuer, test authentication, or establish who owns the value. Treat an unexpected candidate as potentially exposed until it is identified. If it could be real, rotate or revoke it through the relevant provider and review every place the diff was shared.

Is deleting the secret in a later commit enough?

No. Deleting the value removes it from the newest file version, but an earlier commit may remain in repository history, forks, caches, review systems, clones, or copied patches. If exposure is possible, rotate the credential rather than relying on deletion. History rewriting can reduce later access to the old commit, but it cannot make an already disclosed credential safe to keep using.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools