🚀 Feature Request: Built-in usePathname() equivalent for Server Components (without Suspense)

[intZaibi]

Goals

1. In Client Components, we have access to usePathname() from next/navigation, which makes accessing the current pathname straightforward and synchronous.

2. Provide a built-in API for Server Components to access the current pathname without requiring:

• Custom middleware
• Custom headers
• Awaiting headers()
• Wrapping components in boundaries

3. Ensure compatibility with cacheComponents in Next.js 16 without forcing unnecessary suspension.

Background

Currently, Server Components do not have direct access to the current pathname.

What we do now:

1. Add middleware to inject the pathname into a custom header.
2. Read that header inside a Server Component using headers().
3. Await headers() (since it returns a Promise in Next.js 16).
4. Wrap the component in due to the async call.

Example of the current workaround:

// Proxy.ts
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function proxy(request: NextRequest) {
  const headers = new Headers(request.headers);
  headers.set("x-pathname", request.nextUrl.pathname);
  return NextResponse.next({request: { headers }});
}

export const config = {
  matcher: ["/((?!api|_next/static|_next/image|favicon.ico).*)"],
};

// Parent
<Suspense fallback={<NavLinksSkeleton/>}>
  <NavLinks/>
</Suspense>

// Component
async function NavLinks() {
  const headersList = await headers();
  const pathname = headersList.get("x-pathname");

  return (
    <span className={pathname === "/about" ? "active" : ""}>
      About
    </span>
  );
}

Problems with this approach:

• Requires middleware solely to expose the pathname.
• Forces the component to become async.
• With cacheComponents enabled, awaiting headers() requires a boundary.
• Suspends the entire component tree unnecessarily for something as trivial as reading the current route.
• Feels inconsistent compared to the simplicity of usePathname() in Client Components.

Accessing the current pathname is a very common requirement (e.g., active nav links), and the current solution feels over-engineered.

Proposal

Introduce a built-in synchronous API for Server Components, such as:

import { getPathname } from "next/navigation";

const pathname = getPathname();

Requirements:

• Must work in Server Components.
• Must not require await.
• Must not trigger suspension.
• Must work seamlessly with cacheComponents.
• Should behave similarly to how route params are accessible in layouts/pages.

Why This Matters:

• Cleaner developer experience.
• Removes unnecessary middleware.
• Avoids forcing Suspense boundaries for trivial routing logic.
• Keeps navigation-related concerns simple and consistent across Client and Server Components.
• Encourages proper Server Component usage without resorting to client-side fallbacks.

[lubieowoce]

the pathname is not available in server components by design. app router is designed to be able to re-use shared layouts across navigations, but that means they can't access the pathname -- otherwise, we'd risk displaying a stale pathname in a shared layout. also note that await pathname() would still have to be dynamic if params are present.

middleware also makes this difficult. if i rewrite /foo and /bar to /underlying, then presumably we'd want RSC to see different pathnames for those, because if you probably want the pathname that's visible to the browser, not the underlying route. so this'd be another thing that breaks cachability.