Supabase redirects to localhost:3000 after login or email confirmation ('requested path is invalid')

Symptoms

• A user signs up or clicks the confirmation email and lands on http://localhost:3000, a dead page on their own machine
• Supabase shows 'requested path is invalid'
• Google OAuth sign-in bounces back to the wrong URL
• The login loop variant: sign-in appears to succeed on the production domain, then immediately returns to the login screen

Why it happens

Site URL still points at the localhost default

Supabase's Auth Site URL defaults to http://localhost:3000 and is used as the redirect target for confirmation emails, password resets, and OAuth whenever no explicit redirectTo is given, or the given one is not allow-listed.

The Redirect URLs allow-list is missing your environments

Lovable preview URLs and the production domain must be on the Redirect URLs allow-list. 'Requested path is invalid' means the requested redirect was not on that list.

Google OAuth has its own allow-lists

Google needs the production origin in its authorized JavaScript origins and the Supabase callback URL in its authorized redirect URIs, separately from anything you configure in Supabase.

How to fix it

1. Set the Site URL to productionIn Supabase, go to Authentication > URL Configuration and set Site URL to your real production URL, either your custom domain or the *.lovable.app URL. The default is http://localhost:3000, and that default is exactly where your users are being sent.
2. Allow-list every environment in Redirect URLsAdd the Lovable preview URL, the published lovable.app URL, and your custom domain to Redirect URLs. Wildcards like https://*.lovable.app/** are accepted. 'Requested path is invalid' means the redirect the app asked for was not on this list.
3. Pass redirectTo explicitly in codeOn signUp and OAuth calls, pass emailRedirectTo / redirectTo explicitly, for example redirectTo: window.location.origin, so the flow never falls back to the Site URL. Lovable's Supabase auth guide recommends this.
4. Fix Google OAuth's own allow-listsIn Google Cloud Console, add your production domain to Authorized JavaScript origins and add the Supabase callback URL, https://<project-ref>.supabase.co/auth/v1/callback, to Authorized redirect URIs. Google enforces these separately from Supabase's list.
5. Save, then retest with a fresh signupClick Save in Supabase; unsaved URL configuration is a common miss. Then test with a brand-new signup, because old confirmation emails still contain the old redirect and will keep landing on localhost no matter what you fix.
6. Chase the login loop variantIf sign-in succeeds on production and immediately bounces back to the login screen, confirm the domain serving the app exactly matches an allow-listed URL, including https and any www difference.

How to prevent it

• Set Site URL and Redirect URLs the day you connect Supabase auth, before the first real signup.
• Pass redirectTo: window.location.origin on every auth call so environment changes cannot strand users.
• Add each new environment (preview, published URL, custom domain) to Redirect URLs the moment it exists.
• After any auth URL change, test with a fresh signup; old emails carry old links.

Tools that actually fix this

Recommended because they address the failure mode above, not because of the payout. Some are affiliate links; see how we choose.

Frequently asked questions

Sources

• Supabase docs: Redirect URLs
• Supabase GitHub discussion #26483
• Supabase GitHub discussion #30394
• Ishwar Rimal: Fixing the 'login with Google' issue in Lovable with Supabase
• Lovable blog: Supabase authentication step by step
• AppStuck: Lovable troubleshooting guide, the 10 most common errors (2026)

Related errors