If you're building a web or mobile application with Supabase, one of the first configuration steps involves initializing the Supabase client with a URL and an API key.

However, you might notice different terminologies floating around in tutorials, official documentation, or the Supabase dashboard: Anon Key, Publishable Key, Service Role Key, and Secret Key.

What are they? Are they the same? Which one should you expose in your frontend code?

In this post, we'll break down the architectural differences, why Supabase has updated its API key system, and how to keep your database secure.

The Short Answer

The anon key and the publishable key serve the same core purpose: they are low-privilege keys meant to be used on the client-side (frontend, mobile apps) to identify your application.

However, they represent different generations of Supabase's security design: * anon key: This is the legacy key format (a long-lived JSON Web Token, or JWT). * publishable key: This is the modern key format (prefixed with sb_publishable_...), designed to replace the legacy anon key.

Similarly, the legacy service_role key is being replaced by the modern secret key (prefixed with sb_secret_...).

Why Did Supabase Move to the Modern Prefixed Keys?

In the legacy design, the anon and service_role keys were actually JSON Web Tokens (JWTs) signed by a single JWT secret managed by your Supabase project. While this kept client-side authentication extremely simple, it introduced major pain points:

1. The Nightmare of Key Rotation

If a developer accidentally committed the service_role key to a public GitHub repository, rotating it was a heavy operation. Because all keys were generated from the project's master JWT secret, rotating the key meant regenerating that master secret. As a result: * Every logged-in user session in your production app was instantly invalidated. * Any deployed mobile apps containing the hardcoded legacy keys would break, requiring an emergency App Store/Google Play release.

2. Decoupled and Instant Revocation

The new modern keys (sb_publishable_... and sb_secret_...) are not simple client-side JWTs. They are database-backed, audit-ready tokens. This allows you to rotate your client keys instantly from the Supabase dashboard without invalidating active user sessions and without downtime.

3. Better Tooling and Threat Detection

Modern keys start with specific prefixes (sb_publishable_ or sb_secret_). Standard security tools (like GitHub Token Scanning) can immediately flag them if they are leaked in public repositories, helping you prevent data breaches before they happen.