The build finished. No red error banner, no failed step in the chat. But the preview pane is just… white. Empty. You reload it, you open the deployed URL, you try incognito — same blank page every time.
If you searched “lovable blank screen,” “lovable white screen,” or “lovable preview not loading,” this is that bug — and the reason it feels so stuck is that the blank page is hiding the actual error from you. The app didn’t fail to build. It built fine, then crashed the instant it tried to render, and a crashed React app shows you nothing at all. The good news: the real error is one keystroke away, and once you can see it, the fix is usually small.
Why a Lovable preview goes completely blank
Lovable builds a React app (Vite + React under the hood). React renders your whole app by mounting one component tree into a single root element on the page. If any component in that tree throws an error while it’s rendering — before Lovable’s build step can catch it, because it’s a runtime error, not a build error — React unmounts the entire tree rather than showing a half-broken page. What’s left on screen is the empty root div: a blank white screen.
That’s the key thing to understand: a blank preview almost never means “nothing happened.” It means something threw during render, and the crash took the whole page down with it. The build passing and the screen being blank are not a contradiction — build-time and run-time are two different moments, and this bug lives in the second one.
This is also why “ask Lovable to fix it” often spins in circles: without the specific runtime error, the agent is guessing at which of a dozen things went wrong, the same way you are.
The one move that finds the real error
Before you touch a prompt, get the actual error message. It’s sitting in the browser console.
- With the blank preview on screen, open your browser’s developer tools — F12, or right-click the page and choose Inspect, then click the Console tab. (If the preview runs in its own pane, open the preview in a full browser tab first so the console shows its errors, not Lovable’s editor.)
- Reload the page with the console open and read the first red error, top to bottom. The first one is the cause; the ones below it are usually knock-on effects.
- Copy that exact error text. This one line tells you which of the causes below you’re looking at — and it’s also the single most useful thing you can paste into Lovable if you do hand it back to the agent.
Everything after this is just matching that error to a fix.
The three usual causes — and the fix for each
Nine times out of ten a blank Lovable screen is one of these.
1. A runtime error inside a component (console says something like Cannot read properties of undefined (reading 'map'), X is not a function, or Cannot read property 'name' of null).
This is code trying to use data that isn’t there yet — mapping over a list that’s still undefined on the first render, reading user.name before the user has loaded, destructuring a prop that wasn’t passed. The component throws, and the page goes blank.
- Fix: the console error names the file and line. Open it and guard the access: render nothing (or a loading state) until the data exists —
if (!items) return null;before a.map, or optional chaining likeuser?.name. If you’re handing it to Lovable, name the file and paste the error: “InDashboard.tsx,itemsis undefined on first render anditems.mapthrows — add a guard so it doesn’t run untilitemsis loaded.”
2. A failed or bad import (console says Failed to resolve import, does not provide an export named 'X', or a module path that 404s).
Something is importing a file or package that doesn’t exist, moved, or exports a different name than the import expects — often after the agent renamed a component, split a file, or referenced a library that was never actually installed.
- Fix: open the file the error points at and check the import line against reality — does the path match where the file actually lives, and does the exported name match (default vs named export is a common mismatch)? If it’s a missing package, ask Lovable to install it explicitly rather than assuming it’s there. Renamed-component blank screens are extremely common right after a big refactor prompt.
3. A missing environment variable crashing initialization (console says something like supabaseUrl is required, Invalid API key, or an error thrown from a client-setup file at the top of the app).
If your app creates a client at startup (Supabase, a payments SDK, any API client) using a key that’s undefined, that constructor can throw before a single screen renders — taking the whole app down to a blank page. The variable exists in one place (your local setup, or the preview) but isn’t wired into the environment the blank build is actually reading from.
- Fix: the error usually names the missing value. Check that the variable is set in Lovable’s environment/secrets for the environment you’re looking at, that the name matches exactly (a
VITE_prefix is required for client-side vars in a Vite app — a var without it reads asundefinedin the browser), and that you redeploy/reload after adding it, since env changes don’t apply to an already-loaded page.
How to confirm it’s actually fixed
Don’t just watch the blank page turn into content and move on — confirm the console is clean, or the next render can crash the same way.
- Reload the preview with the console still open and check there are no red errors — not just that something appeared on screen. An app can render its first screen and still be one navigation away from the same crash.
- Click through to the screen or action that was blank originally, not just the landing page — if the crash was in a specific component, you need to actually reach it.
- If the fix was an environment variable, hard-reload (or reopen the deployed URL fresh) rather than trusting the already-open tab, since the old value may be cached in the loaded page.
- If you handed the fix to Lovable, re-open the console afterward and verify the specific error you started with is gone — agents sometimes “fix” a blank screen by changing something unrelated that happens to render a page, leaving the original bug one click away.
Comments
Sign in to join the conversation.
No comments yet — be the first.