API key leak checker
A secret key is meant to stay on your server. When it ships in the code the browser downloads, anyone can copy it. This free checker reads your live JavaScript and looks for keys that should not be there.
Run the check
What this checks
It scans your shipped bundles against known key formats for Stripe, OpenAI, AWS, Google, Supabase and more. It flags secret and service keys, and deliberately does not flag public keys that are designed to ship, like the Supabase anon key.
Why it gets missed
To make a feature work, an AI tool sometimes pastes a key straight into a file instead of a server-only environment variable. It runs fine, so nothing warns you, and if that file is part of the frontend the key reaches every visitor.
See the full step-by-step fix, with a copy-paste block for your AI tool →
What a finding shows you
The kind of key (a Stripe live secret key, an AWS access key, a Supabase secret key and so on), the file it was found in, and the key itself masked to its first and last few characters. The full value is never shown or stored.
How sure xlogs is, in two parts: that it saw the key in code your site serves, and what that means, which stays potential because xlogs never uses a key to test whether it works.
Fix instructions to copy into your coding assistant, starting with containing and rotating the key.
What it reads, and what it does not
Your homepage's HTML and inline scripts, and up to 25 JavaScript bundles your site serves from its own domain, checked against 18 key formats.
It does not read code that is never sent to a browser: your repository, your server functions or your environment variables. It does not log in, so code that loads only for a signed-in user is not read. And it never uses a key it finds, so whether the key still works is not tested.
Keys designed to ship in a browser are not reported as leaks: a Supabase anon or publishable key, or a Stripe publishable key, is meant to be public. Whether such a key can read data it should not is a question about your database rules, which is a different check.
If it finds a key
Rotate it first, because removing it from the code does not stop a copy from working: revoke it at once if you suspect misuse; otherwise create a replacement, confirm the app works with it, then revoke the old one.
Then move the key to a server-only environment variable, call the service from a backend route, and redeploy.
Rescan after you deploy. The recheck says whether the key is still found in what xlogs reads; it cannot show that the old key was revoked, so do that at the provider either way.