Paste your Flutter + supabase_flutter OAuth / magic-link deep link config and get exact mismatch fixes before wasting another afternoon.
Runs entirely in your browser. No account, no backend, no payment.
redirectTo, CFBundleURLSchemes, the AndroidManifest intent-filter, and the Supabase redirect allow-list are four separate places that must agree on the exact same string — miss one and the OS never hands the link back to your app.
A scheme like my_app://callback looks fine everywhere you check it — until Google's OAuth redirect handling mangles the underscore and Supabase's redirect check always fails (supabase/auth#2447), quietly falling back to Site URL.
LaunchMode.inAppWebView gets detected and blocked by Kakao, Discord, and Facebook's OAuth screens, and implicit flow puts the session in a URL fragment that deep links don't always preserve — both leave the user stuck mid-flow.
import { diagnose } from './doctor-flutter.js'; // or, loaded globally: const { diagnose } = window.RedirectDoctorFlutter; const result = diagnose({ app: { scheme, host, launchMode, authFlowType, iosSchemesInPlist, androidIntentFilter }, supabase: { projectUrl, siteUrl, allowedRedirectUrls }, provider: { name, authorizedRedirectUris }, code: { redirectTo, usesSkipBrowserRedirect, listensToAuthStateChange }, }); // result { "status": "fail" | "warn" | "pass", "summary": "…", "expected": { redirectTo, iosPlistScheme, androidIntentFilter, allowListEntry, supabaseCallback }, "problems": [ { severity, code, message, where } ], "fixes": [ { title, value, where } ], "checklist": [ "…" ], "disclaimer": "…" }
Everything runs client-side. The form above calls this exact function in your browser. There is no backend, no API key, and no request that carries your config anywhere.
It checks the deep link your app will actually register — computed once from scheme + host — against Info.plist, the AndroidManifest intent-filter, the Supabase redirect allow-list, and the exact callback your OAuth provider console expects.
This started as a tool I needed myself. If it saves you an afternoon, the best way to say thanks is to tell me what it got wrong — open a GitHub issue.
Read-only, client-side analysis. Nothing you enter is sent anywhere — the check runs entirely in your browser against the values you typed, not your live project. Always verify in your own environment. Not affiliated with Supabase, Google, Apple, GitHub, Discord, Kakao, or the Flutter project.
The most common cause is a mismatch between the scheme/host your Dart code sends as redirectTo and the <data android:scheme android:host> values declared in the AndroidManifest.xml intent-filter — if they don't match exactly, Android has nothing registered to catch the link. The second most common cause is an underscore in the scheme: Google's OAuth redirect handling mangles underscores, so a scheme like my_app always fails Supabase's redirect-URL check and silently falls back to Site URL (supabase/auth#2447).
Use the exact scheme://host form documented by Supabase, e.g. io.supabase.myapp://login-callback — no trailing slash, no extra path. That same string must appear unchanged in four places: the redirectTo argument, Info.plist's CFBundleURLSchemes, the AndroidManifest intent-filter, and the Supabase redirect allow-list.
Yes. Supabase's own auth repository documents this as a known issue (supabase/auth#2447): a redirect URL containing an underscore, such as my_app://callback, is mangled by Google's OAuth handling and will always fail Supabase's redirect-URL match, falling back to Site URL instead of returning to the app. Use a hyphen instead — my-app://callback — or a dotted reverse-domain scheme like io.supabase.myapp.
Set authScreenLaunchMode: LaunchMode.externalApplication. It opens the provider's OAuth screen in the system browser, which is what hands control back to the OS to fire your app's custom-scheme intent-filter / CFBundleURLSchemes entry. LaunchMode.inAppWebView embeds a WebView instead, and Kakao, Discord, and Facebook among others detect that and either refuse to complete sign-in or never trigger the redirect back out.
In ios/Runner/Info.plist, add a CFBundleURLTypes array containing a dict whose CFBundleURLSchemes array lists your scheme. In android/app/src/main/AndroidManifest.xml, add an intent-filter to your launch activity with action VIEW, categories DEFAULT and BROWSABLE, and a <data android:scheme="…" android:host="…" /> element matching your redirectTo exactly. Leave android:autoVerify off — it only does anything for https Android App Links.
Google Cloud Console's "Authorized redirect URIs" needs Supabase's own callback, https://<your-project-ref>.supabase.co/auth/v1/callback — never your app's custom scheme. Google redirects to Supabase first at that URL, and only then does Supabase redirect on to your Flutter app's scheme://host; your app's deep link never goes in the provider console.
Paste your config, get the exact mismatch, fix it, ship it — free, and it never leaves your browser.