Can I expose this key? Paste it. Your keys never leave this page.
Paste a key, a KEY=value line, or your whole .env file. We classify every entry as safe to expose, server-only, or framework-exposed, with rotation steps per provider. The analysis runs entirely client-side: zero network requests, nothing stored. Check the Network tab if you like.
Three kinds of keys
Safe to expose
Publishable by design: Stripe pk_, Supabase anon (with RLS on), PostHog phc_, GA measurement IDs, Mapbox pk. tokens. Each one carries a condition worth checking.
Server-only
Stripe sk_, OpenAI and Anthropic keys, Supabase service_role, database URLs, webhook signing secrets, AWS credentials. In a browser bundle these are incidents, not settings.
Framework-exposed
NEXT_PUBLIC_, VITE_, REACT_APP_, EXPO_PUBLIC_, NUXT_PUBLIC_: the NAME ships the value to every visitor. A server secret under a public prefix is the classic AI-built-app leak.
Straight answers
Do my keys leave the browser?
No. The analysis is a pure function that runs in your browser. The analyze flow makes zero network requests: no fetch, no beacon, nothing stored. You can verify this yourself in DevTools: open the Network tab, paste a key, click Analyze, and watch nothing fire.
Is it safe to expose a Supabase anon key?
Yes, but only if Row Level Security is enabled on every table with real policies. The anon key is designed for browsers; RLS is the actual security boundary. With RLS off, the anon key reads your whole database. We decode the JWT locally and confirm the role claim is anon, not service_role.
What is the difference between a Stripe publishable key and a secret key?
The publishable key (pk_live_ or pk_test_) is designed for frontend code: it can tokenize cards and start Checkout, nothing more. The secret key (sk_live_ or sk_test_) can charge, refund, and read customer data, and must only exist in server code. If sk_ ever ships in your bundle, roll it in the Stripe dashboard immediately.
Does NEXT_PUBLIC_ make an environment variable safe?
The opposite. NEXT_PUBLIC_ (like VITE_, REACT_APP_, EXPO_PUBLIC_, NUXT_PUBLIC_) tells the framework to ship the value into the client bundle. It is a publishing instruction, not a protection. Putting a server secret under a NEXT_PUBLIC_ name is the single most common way AI-built apps leak keys.
What should I do if I already exposed a secret key?
Rotate first, clean up second. Create a new key in the provider dashboard, deploy it server-side, then revoke the old one. Deleting the code is not enough: old bundles, git history, and scrapers keep leaked keys alive. Then check your provider usage logs for activity you do not recognize.
What if my key is not recognized?
We fail toward safety. Unknown values get an entropy check and name analysis, and the verdict is "treat as server-only until proven otherwise". We only say "safe to expose" for key formats that are documented as publishable by their provider.