Supabase Publishable Key vs Anon Key: What Actually Matters

Supabase key naming can be confusing, especially if you are reading older tutorials while using a newer Supabase project.

You may see:

• anon key
• publishable key
• service_role key
• secret key

If you are building a frontend app, the main question is usually:

The answer depends on the key type, but the security model is bigger than the key name.

The simple rule

For frontend code:

For backend code:

Do not put server secrets in browser code.

Why the naming causes confusion

Many older Supabase examples use the anon key in frontend code.

Newer projects may emphasize publishable keys.

This can lead developers to ask:

• Is the anon key deprecated?
• Is the publishable key safer?
• Can users see it?
• Does this replace RLS?

The key point is:

Changing the key name does not remove the need for authorization rules.

What a frontend key can do

A frontend Supabase key allows the browser client to talk to Supabase.

But the database should still enforce what that client can access.

That enforcement comes from:

• authentication state
• RLS policies
• storage policies
• allowed operations
• table design

The key opens the door to Supabase.

RLS decides which rooms the user can enter.

What should not be public

Never expose keys that can bypass user-level policies.

For example:

SUPABASE_SERVICE_ROLE_KEY=...

This belongs on the server only.

In Next.js, avoid this mistake:

NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY=...

The NEXT_PUBLIC_ prefix means it can be exposed to the browser.

That is not what you want for a secret.

A safe environment variable pattern

For frontend:

NEXT_PUBLIC_SUPABASE_URL=...
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=...

For server-only usage:

SUPABASE_URL=...
SUPABASE_SERVICE_ROLE_KEY=...

Then use the frontend key only in browser/client code.

Use the service role key only in trusted server code.

Do not use key changes to hide policy bugs

If you get this error:

new row violates row-level security policy

The fix is usually not to switch to a more powerful key.

The fix is to write the correct policy.

For example:

create policy "Users can insert their own rows"
on todos
for insert
to authenticated
with check (
  auth.uid() = user_id
);

That policy expresses the actual rule:

That is better than bypassing RLS.

Practical decision tree

Ask:

1. Is this code running in the browser?

Use a public frontend key.

2. Is this code running on the server?

You may use a secret key if the operation truly needs it.

3. Is this normal user data access?

Use RLS.

4. Is this an admin operation?

Keep it server-only and narrow.

What I use as a safety check

Before shipping, I check:

• No service_role key in frontend code
• No secret key with NEXT_PUBLIC_
• RLS enabled on user data tables
• Separate policies for select, insert, update, and delete
• Negative tests for cross-user access
• Storage policies reviewed separately

Most production issues come from skipping one of those.

A small guide I made

I built FixRLS to help developers generate Supabase key placement guidance and RLS starting points without connecting to their project or asking for secrets.

For publishable key guidance, start here:

https://fixrls.dev/supabase-publishable-key

Final thought

The publishable key vs anon key question matters, but it is not the whole security story.

The bigger rule is:

Related FixRLS page

For this specific issue, use the matching FixRLS page: https://fixrls.dev/supabase-publishable-key