Google sign-in shows your supabase.co URL: fix it with a Supabase custom domain

Why Google shows <project-ref>.supabase.co

With Supabase Auth, the OAuth redirect URI registered in Google Cloud is https://<project-ref>.supabase.co/auth/v1/callback. Two separate settings decide what users see on Google's screen:

• The domain. Supabase's Google guide says that without a custom domain, users see <project-id>.supabase.co, which "does not inspire trust" and can make phishing easier. Google's branding help adds that without verification, only your application domain is visible to users.
• The app name and logo. Google shows your app name on the OAuth consent screen only after your app's brand has been through verification.

So there are two fixes, and you may want both:

For the app-name side in detail, see why Google shows the wrong app name on sign-in.

Option 1: Add a Supabase custom domain

Requirements from Supabase's docs: a project on a paid plan with the custom domain add-on, Owner or Admin permissions, the latest Supabase CLI, and a subdomain you control (for example auth.example.com or api.example.com; an apex like example.com isn't supported). One custom domain per project.

The dashboard route is the Custom Domains section of the project's General Settings (as of Oct 2026). The CLI steps below do the same thing.

1. Point a CNAME at your project

At your DNS provider, create:

auth.example.com.  CNAME  <project-ref>.supabase.co.

Use a low TTL so you can correct mistakes quickly.

2. Register the domain and add the TXT record

supabase domains create --project-ref <project-ref> --custom-hostname auth.example.com

The command prints a TXT record for _acme-challenge.auth.example.com. Add it to DNS with surrounding whitespace trimmed. If your registrar appends your domain automatically, enter only _acme-challenge.auth as the name.

3. Verify DNS and wait for the certificate

supabase domains reverify --project-ref <project-ref>

Run it again if DNS hasn't propagated yet. Supabase then issues the TLS certificate, which can take up to 30 minutes.

4. Add the new callback to Google Cloud before activating

Supabase's docs say Auth uses the custom domain immediately once activated, and OAuth flows advertise it as the callback URL. If that URI isn't registered on your Google client yet, Google can reject sign-in with redirect_uri_mismatch. So first, in the Google Auth Platform console (as of Oct 2026):

1. Under Branding → Authorized domains, add example.com if it isn't there. Google asks you to add authorized domains before adding redirect or origin URIs.
2. Under Clients, open the Web client whose ID is saved in Supabase and add the new callback alongside the existing one:

https://<project-ref>.supabase.co/auth/v1/callback
https://auth.example.com/auth/v1/callback

3. Save, and allow time: Google says changes to these settings can take 5 minutes to a few hours to take effect.

Do this in Google Cloud, not in the Supabase dashboard. Repeat it for every other OAuth provider you've enabled.

5. Activate the custom domain

supabase domains activate --project-ref <project-ref>

The <project-ref>.supabase.co domain keeps working, so existing clients don't break. You can optionally switch your client to the new domain:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient('https://auth.example.com', '<your-publishable-key>')

After activation, Edge Functions and Storage are also served from the custom domain (their supabase.co URLs keep working). Activation also changes the SAML EntityID, so ask any SAML identity providers to update their metadata before you activate.

Vanity subdomain (lighter alternative)

A vanity subdomain replaces the random ref with a name of your choice, still on Supabase's domain (for example my-brand.supabase.co). Supabase marks it experimental and CLI-only, requires the organization to be on a paid plan, and lets a project use either a vanity subdomain or a custom domain, not both:

supabase vanity-subdomains check-availability --project-ref <project-ref> --desired-subdomain my-brand --experimental
supabase vanity-subdomains activate --project-ref <project-ref> --desired-subdomain my-brand --experimental

The same rule applies: add https://my-brand.supabase.co/auth/v1/callback to Google first. The callback domain becomes my-brand.supabase.co, which is more recognizable but still a supabase.co address.

Option 2: Get your app name on the screen (Google brand verification)

In the Google Auth Platform console, open Branding (as of Oct 2026), set the app name, logo, home page, privacy policy and terms links on domains you've authorized, then click Verify Branding on the same page and track progress in the Verification Center. Google says the check usually completes in a few minutes; Supabase notes brand verification is not automatic and may take a few business days. You can't edit branding while verification is in progress. This step is independent of the custom domain.

How to confirm it worked

1. In a private window, click "Sign in with Google" on your app.
2. On Google's screen, read the redirect_uri parameter in the address bar. It should now be https://auth.example.com/auth/v1/callback.
3. Google's screen should no longer name <project-ref>.supabase.co (and should show your app name once branding is approved).
4. Finish sign-in. If Google shows redirect_uri_mismatch, the new callback isn't on the client yet or hasn't propagated; see redirect_uri_mismatch.

Related problems

• Using Firebase instead of Supabase? The same issue appears as "continue to .firebaseapp.com": see continue to firebaseapp.com and changing the Firebase authDomain.
• First-time setup: Supabase Google OAuth setup.