Client-Side Secret Exposure Checker

Scan JavaScript, config or any pasted text for API keys, tokens and credentials using high-confidence patterns plus entropy, with every match masked and nothing uploaded.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Code, configuration or any text to scan Scanned in your browser. Nothing is uploaded, and no value is ever shown in full.

Or drop a file here

Up to 10 MB. Read locally.

Anything shipped to a browser is already public

That is the premise this tool works from. A key in front-end JavaScript is not hidden by minification, obfuscation or a build step - it is downloaded, in full, by everyone who visits, and it is trivially readable in developer tools. There is no way to put a secret in client-side code and keep it secret.

So if this tool finds something real, the order of operations matters: rotate the credential first, then remove it from the code. Removing it without rotating changes nothing, because it has been public since the day it deployed and you have no way of knowing who already has it.

Nothing you paste leaves your browser, and nothing is shown in full

The scan runs entirely in the page. There is no upload and no request carrying your input. Every finding is masked to a prefix, a suffix and a length - enough to locate the value in your own code, and not enough to use if this page ends up in a screenshot, a ticket or a shared terminal. The CSV export is masked too.

Clear everything wipes the results as well as the input, because a results panel full of masked findings is still a map of where the secrets are.

Two kinds of detection, kept apart on purpose

Known vendor formats - high confidence

AWS keys start AKIA or ASIA and are exactly 20 characters. GitHub tokens start ghp_. Stripe live secrets start sk_live_. These formats are documented, distinctive, and essentially nothing else looks like them, so a match is reported as a finding with a severity reflecting what the credential typically grants.

Entropy and naming - a heuristic, and labelled as one

For credentials with no recognisable format, the tool looks for a suspicious variable name and a high-entropy value, and requires both. Either alone is useless: entropy on its own reports every minified identifier and every base64 image, and a suspicious name on its own reports apiKeyName = "userApiKey".

Even with both, this is a guess, and the tool presents it in a separate section rather than mixing it in with the certain findings.

What it rules out, and why that is shown

Hashes, UUIDs, git commit SHAs, SRI integrity values, long base64 assets and publishable identifiers all look like secrets to an entropy test. The tool recognises them and lists them in a ruled out section with the reason.

Showing that is deliberate. A tool that silently filters is asking to be trusted; one that shows its reasoning lets you disagree with it. If something in that list is actually a secret, you can see that it was dismissed and why.

Some public keys are meant to be public

This catches people out and causes unnecessary incident calls, so it is worth being explicit:

Google API keys (AIza...) for Maps or reCAPTCHA are meant to be in the page. They are protected by HTTP referrer and API restrictions in the Google console, not by secrecy. The tool reports them at medium severity with that note - the action is to check the restrictions, not to panic.
Stripe publishable keys (pk_live_) are designed to be public and are not reported at all. Only sk_live_ and rk_live_ are.
Firebase apiKey in a firebaseConfig object is a project identifier, not a credential. Firebase security rules are the control. The tool does not report it.

What this cannot find

It matches known formats and a naming-plus-entropy heuristic against the text you give it. A bespoke internal credential format with no distinctive shape and an innocuous variable name will not be found. A secret split across several variables and concatenated at runtime will not be found. A clean result means nothing matched in this input, which is not the same as there is nothing here.

For continuous coverage, run a secret scanner in CI against your repository and enable your hosting provider's push protection. This tool is for the ad-hoc case: a bundle you have just been handed, a config file before you commit it, a log before you attach it to a ticket.

To strip secrets and personal data out of something before sharing it, use PII and Secret Redactor. To check what a live site exposes, use JavaScript Source Map Exposure Checker.

Frequently asked questions

Is my code uploaded anywhere?

No. The entire scan runs in your browser. There is no network request carrying your input, nothing is written to storage, and the export is generated locally.

Why can I not see the full value of a finding?

Because this page could end up in a screenshot, a recording or a shared machine. A masked value plus a line number is enough to find it in your own code, which is all the tool needs to be useful.

It flagged a Google Maps key. Is that a leak?

Almost certainly not. Maps and reCAPTCHA keys belong in the page and are secured with referrer and API restrictions rather than secrecy. Check those restrictions in the Google console. The tool reports it so you can confirm, not because it assumes the worst.

I removed the key from my code. Am I done?

Not unless you rotated it. Anything that shipped to browsers has been public since deploy, and it is also in git history and in any CDN cache. Rotate first; removing it afterwards is the tidy-up.

Why require both a suspicious name and high entropy?

Because either alone produces mostly noise. Minified JavaScript is full of high-entropy strings that are not secrets, and plenty of variables have secret-sounding names holding ordinary values. Requiring both keeps the heuristic section short enough to actually read.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.