How to Debug a Next.js Application in VS Code (Complete Guide)
Next.js has two separate debugging environments: server and client. Here's how to attach VS Code to both simultaneously, debug Server Components, API routes, hydration errors, and middleware with breakpoints that actually work.
Two Environments, Two Debuggers
Next.js runs code in two separate places. The server handles Server Components, API routes, and middleware. The browser handles Client Components, state, and events. VS Code can attach to both at the same time.
| Environment | What runs here | How to debug |
|---|---|---|
| Server | Server Components, API routes, middleware, getServerSideProps | VS Code Node.js debugger |
| Client | Client Components ('use client'), browser events, state | Browser DevTools + VS Code Chrome debugger |
Errors in Server Components show up in the terminal. Errors in Client Components show up in the browser console. Knowing which side the error is on tells you which tool to open.
Step 1: Configure VS Code
Create .vscode/launch.json in your project root:
Use "Next.js: debug full stack" to attach to both server and browser at once. Breakpoints in Server Components and Client Components both pause in VS Code.
Step 2: Debug Server Components
Server Components run on Node.js. Errors show up in the terminal where npm run dev is running, not in the browser.
Set a breakpoint on fetchUserData(). VS Code pauses when the page loads and you can inspect data before it hits the component.
Note: Server Components run on every request, so breakpoints fire every page visit. Right-click a breakpoint and add a condition to avoid pausing on every load.
Step 3: Debug Client Components
Client Components run in the browser. With "Next.js: debug full stack" active, breakpoints in 'use client' files still pause in VS Code, not the browser. Source maps handle the translation.
Tip: If breakpoints in Client Components show as unbound, check that
sourceMapPathOverridesin your launch config maps webpack paths to your source directory. The default Next.js config usually works without changes.
Step 4: Debug API Routes
API routes in app/api/ or pages/api/ run on the server. Debug them the same way as Server Components.
Trigger the route with curl while the debugger is attached:
VS Code pauses, you inspect body, step through createUser, and see what gets returned.
Step 5: Fix Hydration Errors
The most common Next.js error:
This happens when the server renders one thing and the client renders something different during hydration.
Browser-only API used outside useEffect
Date or random value rendered on both sides
Step 6: Debug Middleware
Middleware runs at the edge before the request reaches your route. Errors here are silent by default and won't show up in the normal error overlay.
Note: Middleware runs in the Edge Runtime, not Node.js. VS Code's Node debugger can't attach to it. Use
console.logand check the terminal output.
Common Errors Quick Reference
| Error | Environment | Cause |
|---|---|---|
| Hydration failed | Client | Server and client rendered different output |
window is not defined | Server | Browser API used in a Server Component |
useEffect not available | Server | Client hook in Server Component, add 'use client' |
| 404 on dynamic route | Server | generateStaticParams returned empty or dynamicParams = false |
| Middleware redirect loop | Edge | Redirect target matches middleware pattern, add exclusion |
| CORS on API route | Server | Missing Access-Control-Allow-Origin header in response |
For Next.js bugs that cross Server Components, Client Components, and API routes — especially when the wrong data arrives at the wrong component — paste the error and component tree into DebugAI. It traces the full chain from server fetch to client render and shows where the data goes wrong.
Debug faster starting today.
Free VS Code extension. 10 sessions/day. No credit card.