Skip to content
apikey.tools
SCANScanners

Secret String Masker & Redaction Utility

Redact a credential so it can appear in a ticket, log or screenshot without being usable.

SCANRuns in this tabInput not transmitted

Input

One value per line to mask several at once.

chars
chars

Output

computing

You need to talk about a credential without disclosing it — in a bug report, a support thread, a log line, or a screen share. Masking keeps the parts that identify the key and removes the parts that make it usable.

Four and four

The convention of showing the first four and last four characters is not arbitrary. It gives you enough to answer "is this the same key?" while leaving the search space essentially untouched.

Revealing more is worse than it looks. Each disclosed character of a Base62 key removes about 6 bits of entropy from the attacker's problem. Twelve revealed characters is 71 bits gone — on a key that started with 128, that is most of its strength. This tool flags anything above eight revealed characters as too much.

Keep the prefix

sk_live_ is not secret. Keeping it means the masked value still says which service and environment the credential belongs to, which is usually the whole point of mentioning it. The prefix contributes no entropy, so preserving it costs nothing.

Do not preserve the length

The default hides the exact length behind a character count. That is deliberate: knowing a key is exactly 43 characters tells an attacker the encoding and the byte count, which narrows the search. Preserving length is available when visual alignment matters more, but off is the safer default.

The log line format

The second output is more useful than the masked value for anything automated:

key_id=sk_live_ last4=7f2a len=43

Log an identifier and a fingerprint, never the credential. This gives support enough to correlate a request with a key record, gives you enough to answer "which key made this call", and gives an attacker who reads your logs nothing.

Better still, log the key's database ID rather than any part of the key itself. The key vendor detector produces a SHA-256 fingerprint that serves the same purpose with no disclosure at all.

Masking is not protection

A masked key in a ticket is safe. The unmasked key in the previous message in that ticket is not. Masking helps at the moment of disclosure; it does nothing about the copy that already leaked. If the value has been exposed anywhere, rotate it — the revocation generator has the commands.

Frequently asked questions

How many characters are safe to show?

Eight total — four at each end. Beyond that you are materially helping an attacker. Below that you may not be able to tell two keys apart, which defeats the purpose.

Can I mask several values at once?

Yes. Put one per line and each is masked independently, with prefixes detected per line. Useful for redacting a column of credentials before pasting a table into a document.

Is a masked key safe to post publicly?

With four and four, yes. The remaining search space is essentially the full key. But consider whether you need to post it at all — a fingerprint answers "is this the same key" without revealing any characters.

Should I mask keys in my application logs?

Do not log them at all. Masking at the log line is a mitigation for logs you already have; the fix is to never pass the credential to the logger. Redaction filters fail exactly when a new code path forgets to use them.

More scanners tools

Identify, score and contain exposed credentials