No, 'use client' does not limit rendering to the client—it marks a boundary where JavaScript is bundled for client-side hydration, but the component still renders on the server to generate initial HTML
Using 'use client' in Next.js does NOT mean the component only renders on the client. This is a common misconception. In reality, all components—both Server Components and Client Components—render on the server to generate the initial HTML that users see. The 'use client' directive serves a different purpose: it creates a boundary between server and client execution, marking where client-side JavaScript should be bundled and hydrated after the server-rendered HTML is delivered. Components with 'use client' still run on the server during the initial render, but they also ship JavaScript to the client to become interactive.
Creates a client boundary: When you add 'use client' at the top of a file, it tells Next.js that this component and its imports are part of the client bundle and will be hydrated in the browser.
Server rendering still happens: Client Components are still rendered on the server during the initial page load to generate HTML, ensuring fast First Contentful Paint and SEO benefits.
JavaScript ships to client: After the HTML is delivered, the JavaScript for Client Components is downloaded and executed to hydrate the page and add interactivity.
State and effects become available: Only Client Components can use React hooks like useState, useEffect, and browser APIs because they run in the browser after hydration.
When a request arrives for a page containing a Client Component, the sequence is: First, Next.js renders the entire component tree on the server, including all Client Components. This produces the initial HTML that's sent to the browser. After the HTML loads, React hydrates the page—this means it re-runs the Client Components in the browser, attaches event handlers, and makes the UI interactive. So Client Components execute twice: once on the server (to generate HTML) and once on the client (to become interactive). The 'use client' directive didn't prevent server execution; it simply flagged that this component needs the second client-side pass.
Traditional React (without SSR): Components only render in the browser. No server execution occurs.
Traditional React with SSR: Both server and client render phases exist, similar to Next.js but requiring manual setup.
Next.js App Router: Server rendering is automatic and mandatory for all components during initial page load—there's no opt-out.
The 'use client' directive doesn't control where rendering happens; it controls whether JavaScript is sent to the client.
Next.js's design of rendering all components on the server is intentional and crucial for performance. By pre-rendering Client Components on the server, users see complete HTML immediately, even before JavaScript loads. This gives you the interactivity of Client Components with the performance benefits of server rendering. If 'use client' prevented server rendering, pages would display blank shells until JavaScript downloaded and executed, hurting both perceived performance and SEO. The current model offers the best of both worlds: fast initial paint plus rich interactivity.
Server-side code safety: Even in Client Components, code that accesses server-only APIs (databases, file system) will execute on the server. Ensure you conditionally access browser APIs or use useEffect.
Hydration mismatches: Since components render twice, any differences between server and client output cause React warnings. Use useEffect for browser-specific code or suppressHydrationWarning when necessary.
Bundle size: All code inside Client Components and their imports is included in the client bundle, even if it also runs on the server. Use 'server-only' package to prevent accidental exposure of server code.
Performance: Heavy components that don't need immediate interactivity can use dynamic imports with ssr: false to reduce server load and initial bundle size.