Supabase Redirect URLs explained: allow list, wildcards and local config

Site URL vs Redirect URLs

Neither of these is Google's (or any provider's) redirect URI. The provider always returns to the Supabase callback, https://<project-ref>.supabase.co/auth/v1/callback; the allow list controls the second hop, from Supabase to your app. If your symptom is specifically "production logins end on localhost", go to Supabase Google OAuth redirects to localhost.

How to add or change a redirect URL

Hosted project (dashboard)

1. Open Authentication → URL Configuration in the Supabase dashboard (as of Oct 2026).
2. Under Redirect URLs, add each URL or pattern your app will pass as redirectTo.
3. To change the default destination, edit Site URL on the same page.
4. Pass a matching value from your code:

await supabase.auth.signInWithOAuth({
  provider: 'google',
  options: { redirectTo: 'https://example.com/auth/callback' },
})

Local development and config-as-code (Supabase CLI)

In supabase/config.toml:

[auth]
site_url = "http://localhost:3000"
additional_redirect_urls = [
  "http://localhost:3000/auth/callback",
  "http://127.0.0.1:3000/auth/callback"
]

• Defaults: site_url = "http://localhost:3000" and additional_redirect_urls = ["https://localhost:3000"]. Note the default list entry uses https, while most local dev servers run on plain http, so add your http callback explicitly.
• The CLI reference describes additional_redirect_urls as a list of exact URLs, so list each callback path explicitly for local work.
• Restart the local stack after editing: supabase stop, then supabase start.
• To apply the same file to a linked hosted project, run supabase config push, which updates the linked project's configuration from your local config.toml. Check the file before pushing: a local value such as site_url = "http://localhost:3000" may overwrite your production setting.

Wildcard (glob) syntax

Supabase matches Redirect URLs entries as glob patterns. The separator characters are . and /.

Examples from Supabase's docs:

Supabase recommends ** for local and preview URLs but an exact path for production. Supabase's guide links a glob testing tool so you can check a pattern before saving it.

Preview deployment patterns

Vercel

Keep Site URL on production and add:

http://localhost:3000/**
https://*-<team-or-account-slug>.vercel.app/**

Vercel's generated preview hosts look like <project-name>-<unique-hash>-<scope-slug>.vercel.app (per commit) and <project-name>-git-<branch-name>-<scope-slug>.vercel.app (per branch). Both are a single DNS label before .vercel.app, so *-<scope-slug> matches them, while * can't cross a . into other domains. Then make each preview pass its own URL as redirectTo. In Next.js, NEXT_PUBLIC_* variables are inlined at build time, so scope your production-only NEXT_PUBLIC_SITE_URL to the Production environment or previews will redirect to production. Firebase users with Vercel previews have a different problem: see auth/unauthorized-domain on Vercel.

Netlify

http://localhost:3000/**
https://**--<your-netlify-site>.netlify.app/**

Netlify deploy previews use hosts like deploy-preview-42--<your-netlify-site>.netlify.app, which the **-- prefix covers.

Mobile deep links

Custom schemes work too, for example com.example.app://login-callback/ as the Site URL and com.example.app.staging://login-callback/ as an extra Redirect URL.

Redirect URL not working: troubleshooting

Work through these in order; each one is a common reason a redirectTo is ignored.

1. Exact match. Compare the redirectTo your code sends with the entry character by character: http vs https, www.example.com vs example.com, the port, and the path.
2. Trailing slash. http://localhost:3000/* does not match http://localhost:3000/foo/. Use ** or add the exact URL.
3. * vs **. Use ** when the path has more than one segment (/auth/callback) or the host has extra dots.
4. Truncated Vercel hostnames. Vercel shortens a generated hostname label that would exceed 63 characters. If a preview with a long project or branch name fails, copy the real preview host from the deployment and check it against your pattern.
5. Wrong project. Make sure the dashboard you're editing belongs to the project in your createClient URL (staging and production are separate projects with separate lists).
6. Local list differs from hosted. config.toml only affects the local stack until you run supabase config push.
7. Emails still point at the Site URL. When using redirectTo with magic links or confirmations, replace {{ .SiteURL }} with {{ .RedirectTo }} in your email templates.
8. Errors arrive as a fragment. If sign-in fails, Supabase still redirects to your URL with error_code and error_description in the URL hash. Read them before assuming the redirect itself failed:

const params = new URLSearchParams(window.location.hash.slice(1))
const code = params.get('error_code')
if (code && code.startsWith('4')) {
  alert(params.get('error_description'))
}

If Google itself rejects the request with redirect_uri_mismatch, the problem is in Google Cloud, not in this list: see redirect_uri_mismatch.

How to confirm it worked

1. Trigger sign-in from each environment (production, a preview, localhost).
2. After the provider step, check the browser lands on the redirectTo you passed, not on the Site URL.
3. For local work, confirm the change after supabase stop / supabase start; for hosted projects, reload the URL Configuration page and confirm the entry was saved.