"Application error: a client-side exception has occurred (see the browser console for more information)"

You deployed a Next.js app (often built with v0.dev) and instead of your site, visitors see this one gray sentence. Here is the key fact: this screen is not the error. It is Next.js's last-resort cover page, shown when a JavaScript error escapes while the page is rendering in the browser. Production builds strip the details on purpose, so the screen tells you nothing. The real error is sitting in the browser console, and the message literally tells you where to look.

Step one, before anything else: read the console

Open the broken page. Press F12 (or right click, Inspect) and click the Console tab. Reload the page. Read the first red error, top to bottom. Ignore warnings in yellow and ignore everything after the first red line, because later errors are usually fallout from the first one. That first line decides which fix below applies to you. Do not paste "application error client side exception" back into the AI chat, because that message is generic and the AI will guess. Paste the console error instead and it can actually help.

Fix 1: "Cannot read properties of undefined" (data that never arrived)

Console shows something like TypeError: Cannot read properties of undefined (reading 'map') or (reading 'name'). Your component assumed data exists (data.items.map(...)), but in production the fetch returned nothing, so data is undefined and the render crashes. Why does it only break deployed? Usually because the API call itself fails in production: an API key or database URL lives in your local .env file and was never set on Vercel, or the API base URL points at localhost. Check the Network tab for red failed requests to confirm.

The fix has two parts. First, set every environment variable in Vercel under Settings, then Environment Variables, and then redeploy. Env var changes do not apply to the deploy that already exists; they only take effect on the next build. Second, make the component survive missing data: show a loading state while fetching and guard the access (data?.items?.map(...) or an early if (!data) return ...). Then a failed API call degrades to an empty screen section instead of killing the whole page.

Fix 2: "Hydration failed because the initial UI does not match"

Console mentions hydration, text content mismatch, or "server rendered HTML didn't match". Next.js renders your page on the server first, then the browser renders it again and compares. If the two renders differ, hydration fails. The classic causes are values that only exist or only make sense in the browser: Date.now() or new Date() formatting, Math.random(), window, or localStorage, used directly during render. The server and browser produce different output, and production is stricter about it than dev.

Fix: move browser-only logic out of the render path. Put it in a useEffect and store the result in state, so the first render matches the server and the browser-only value fills in right after. For a whole component that cannot render on the server (maps, charts, editors), load it client-only:

const Chart = dynamic(() => import("../components/Chart"), { ssr: false });

Fix 3: env var is set on Vercel but still undefined (missing NEXT_PUBLIC_)

Console shows an undefined value or a failed request to undefined/api/..., and you swear the variable is set in Vercel. It probably is, but only for the server. Next.js only ships env vars to the browser if the name starts with NEXT_PUBLIC_. A client component reading process.env.API_URL gets undefined in the browser, always, no matter what Vercel says. Rename it to NEXT_PUBLIC_API_URL in Vercel and in the code, then redeploy. One warning: anything with that prefix is visible to every visitor, so never put secret keys behind it. Secrets stay server-side, in API routes or server components.

Fix 4: a library that only breaks in production

Everything works with npm run dev, but the deployed build crashes, and the console error's stack trace mentions a package name from node_modules rather than your own files. Some libraries assume window exists, or break under production minification, or shipped a bad version. The stack trace names the culprit. Options, in order: dynamic-import the component that uses it with ssr: false (Fix 2's snippet), check the package's GitHub issues for your exact error, and pin or downgrade to a known-good version in package.json.

Fix 5: works on your machine, broken deployed, no obvious error

When the console error does not match anything above, run the environment-difference checklist, because that is the whole category this bug lives in. In order: every local .env variable exists in Vercel (compare line by line, typos fail silently). No API URL anywhere says localhost. Your backend's CORS settings allow your deployed domain, not just localhost (the console will say "blocked by CORS policy" if not). And test the deployed site in an incognito window, because a browser extension can inject the exact same crash and send you chasing a bug that does not exist in your code.

Worth ten minutes: error monitoring

This whole page exists because production hides errors. A free error monitoring tool (Sentry's free tier is fine, npx @sentry/wizard@latest -i nextjs sets it up) turns the mystery screen into an emailed report with the exact error, the line, and the browser it happened in. You stop needing a visitor to open devtools for you. Optional, but the ten-minute setup pays for itself the first time this happens while you are asleep.

Still stuck?