Lovable Preview Is Stuck on a White Screen

What does a blank white screen in Lovable usually mean?

A blank white screen is almost always a JavaScript runtime error that stops React from rendering. The two most common causes are a syntax error introduced by the last prompt, or an import that points to a file that no longer exists. Both produce the same symptom: a completely empty page with no visible error — unless you open the browser console and look at the red output there.

Less commonly, the blank screen is an editor sandbox issue only — the underlying preview engine has become stale or hit a memory limit, and a hard refresh clears it. Distinguishing between these two cases before touching anything is the entire job of triage.

A third variant is a Supabase initialization failure: when `supabaseUrl is required` is thrown before React can mount, the entire app fails silently. Check the Console for this exact string if the white screen appeared after a Supabase configuration change.

How do I tell if it's the editor preview or the real app?

Click the external link or pop-out icon in the top-right corner of the Lovable editor to open your deployed build in a new tab. This is the runtime your users actually see — it is separate from the editor preview sandbox. If the pop-out loads normally, your users are unaffected. Only the in-editor sandbox is broken, and a hard refresh of the editor tab will often fix it without any code changes at all.

The in-editor preview and the pop-out runtime run in different environments. The editor sandbox is a hot-reload development environment that can become stale after long sessions or many prompt cycles. The pop-out runtime is a full deployed build. Treating an editor sandbox glitch as a code error — and reverting or prompting to fix it — is a common way to introduce a real error into a working build.

When should I try a hard refresh, and when should I wait?

Try a hard refresh first if: the pop-out runtime loads fine but the editor preview is blank; you have not made any code changes since the preview last worked; or the editor feels sluggish or unresponsive. Check the Lovable status page before assuming the problem is yours — platform incidents affect the editor sandbox first.

1. Check https://status.lovable.dev for any active incidents.
2. Open the pop-out preview to see whether your runtime is healthy.
3. If the pop-out is fine, hard-refresh the editor tab (Ctrl+Shift+R or Cmd+Shift+R).
4. If the editor preview still shows blank, open the browser console (F12) and read the red error.
5. If the error names a file or component, that is the breaking change — go to the timeline.
6. If no error appears in the console, close and reopen the editor tab before touching any code.

When should I revert instead of trying to fix forward?

Revert when the browser console shows a clear error from a recent prompt — for example, a missing export, a failed import, or an undefined variable introduced in the last change. Reverting to the checkpoint before that prompt is faster and cheaper than prompting the AI to diagnose its own mistake. Do not revert if the pop-out preview is healthy: you would be breaking a working app to fix an editor glitch.

1. Open the project timeline and identify the last prompt before the blank screen appeared.
2. Click Revert on the checkpoint immediately before that prompt.
3. Confirm the preview loads correctly in the editor after the revert completes.
4. Then re-try your change as a smaller, isolated prompt.

What if the blank screen comes back after every revert?

If the white screen reappears after reverting — or if reverting to several previous checkpoints does not help — the root cause is something deeper than a single bad prompt. Common structural causes include a circular import between components, a type error that TypeScript cannot resolve, or a Supabase environment variable that changed outside the editor.

A senior engineer can open the browser console, trace the exact error to its source file, and make a targeted fix. That is almost always faster than cycling through prompts that each introduce new guesses into already-broken code.

The **Bug Doom Loop** applies here too: if the same blank screen has appeared after three or more reverting and fixing cycles, each new attempt is compounding the damage. The original error string — the first red line in the console — is the only reliable guide to root cause, and it is worth writing it down before anything else.

How do I confirm the blank screen is actually fixed?

A visual check of the editor preview is not enough to confirm the blank screen is genuinely fixed — the sandbox can show a working page while the deployed build still has an underlying error that users will hit. Run this sequence on the live pop-out runtime to confirm a genuine fix before continuing development or stacking more changes.

1. Open the pop-out deployed runtime and confirm the root route renders without console errors.
2. Navigate to at least two other routes to confirm client-side routing is working.
3. Open DevTools Console (F12) on the live pop-out — confirm zero red errors on any route.
4. If the app uses Supabase, trigger a data read or write and confirm it succeeds in both the UI and the Supabase table viewer.
5. Hard-refresh the pop-out (Ctrl+Shift+R) to bypass any browser cache and confirm the fixed version persists.