Application error: a client-side exception has occurred (Next.js)
Filed under Next.js & React errors
This message is a mask: a real error crashed the page in the visitor's browser, and production Next.js deliberately hides the details — the true error lives in the console and your hosting logs.
Fastest route
Give your AI this prompt
Copy it, replace the bracketed part with your error, and send it.
Preview the prompt
My deployed Next.js site shows "Application error: a client-side exception has occurred" on this page: [page URL or route]. I know this is a generic production message hiding the real error. Here is what I found underneath it: the digest code is [paste digest], and the real error from my hosting logs / browser console is: [paste the real error message and stack]. Here is the code for the page/component involved: [paste the code]. Please: 1) explain in plain English what the real error means and what most likely triggers it in this code, 2) fix that root cause with the smallest possible change, 3) add an error.tsx boundary for this route that shows a friendly fallback and logs the error with its digest. Constraints: do not rewrite the whole page, do not switch libraries, and if the real error above is actually a missing environment variable or data problem rather than a code bug, say so plainly instead of changing code.
Fix it yourself
Follow the repair
- Reproduce the page with the browser console open. Open DevTools first (F12 or right-click, Inspect), select the Console tab, then load the broken page. Even when the page shows only the generic message, the console typically prints more: sometimes the real error text, always the digest. Copy both down before you change anything.
- Match the digest code in your hosting logs. The error page shows a line like "Digest: 2918471629". On Vercel, open your project, go to Logs, and search for that number. The matching entry contains the actual error — message and stack — that a visitor was never shown. That message is your real bug report; every step after this one is about fixing it, not the generic sentence.
- Pin down whether it is one page or every page. Click through a few other routes on the live site. If only this page breaks, the suspect list is that page's component, its data, and its fetches. If everything breaks, think shared causes: the root layout, a context provider wrapping the app, or an environment variable the whole app reads at startup.
- Reproduce production mode on your own machine. Development mode hides this failure behind its helpful overlay, so recreate the real thing locally:
Then open the page on the local production server. You will see the same generic message your visitors see — and now you can experiment freely, with the console and your terminal side by side, until the underlying error shows itself.npm run build npm run start - Work the usual suspects behind the mask. With the real error message in hand, it will usually name one of these directly. Data that is
undefinedon first render (guard it or wait for it). ANEXT_PUBLIC_variable set in your local file but never added in the host's environment settings (add it and redeploy — environment changes need a fresh deployment). Browser-only code likewindoworlocalStoragerunning during server rendering (move it into an effect or a client-only component). A fetch pointing at an address production cannot reach, like your own localhost. - Add an error boundary so the next failure is visible and survivable. Create an
error.tsxfile in the route's folder. It receives the error and its digest, so it can show visitors a friendly "something went wrong" panel with a retry button instead of the generic page — and, just as valuable, it gives you a place to log the real error where you will actually see it. A route-level boundary also confines the damage: one broken component stops taking the whole page down with it.
Why this happensOptional explanation
When a page crashes in development, Next.js shows you a big red overlay with the real error, because you are the developer and you need it. In production it does the opposite on purpose: showing real error messages and stack traces to the public would leak file paths, code details, and sometimes data, so Next.js swaps the whole thing for this one deliberately vague sentence. The crash itself is real — something in that page threw an error in the visitor's browser — but the message you are reading is a curtain, not a diagnosis.
That is why searching for this exact sentence rarely fixes anything. Underneath the curtain it is almost never a mysterious framework failure; it is one of the ordinary runtime errors, wearing a mask. The page reached for data that was not there. A variable the code needs exists on your laptop but was never set in the production environment. Code that expects a browser — window, localStorage — ran while the page was being rendered on the server. The bridge between the mask and the real error is the digest: a short code printed with the message that Next.js also stamps on the full error in your server logs.
- It is production-only by design: the same bug in development shows the real error in an overlay.
- The digest is the lookup key: the generic page and the detailed log entry share the same code.
- Usual hidden causes: undefined data on first render, a missing production environment variable, browser-only APIs during server rendering, an unreachable API.
- One page vs every page tells you whether the fault is in that page's code or in something the whole app shares.
Quick answers
Why does it work in development but break in production?
Development mode shows you the real error in an overlay and is more forgiving about some mistakes. Production minifies the code, hides error details from visitors on purpose, and also uses only the environment variables set on the host — so a missing variable or a hidden runtime error only shows up after deployment.
What is the digest code on the error page?
It is an ID that ties the generic message a visitor sees to the full, real error recorded in your server logs. Find the digest on the error page or in the browser console, search for it in your host's logs (on Vercel: your project, then Logs), and the actual message and stack are waiting there.
Will adding an error boundary tell me what the error is?
Not automatically — but you can add an error.tsx file to a route, which receives the error and its digest, lets you show visitors a friendly fallback instead of the generic page, and gives you a place to log or report the real error so you see it next time.