`useSelectedLayoutSegment` and Building Active Nav Links

useSelectedLayoutSegment reads which route segment is currently active, one level below the layout that calls it. That makes it useful for highlighting an active tab or section link from inside the layout that renders the nav, without needing to parse the full URL path yourself.

App.tsx

// app/blog/blog-nav-link.tsx
"use client";
import Link from "next/link";
import { useSelectedLayoutSegment } from "next/navigation";
export default function BlogNavLink({ slug }: { slug: string }) {
  const segment = useSelectedLayoutSegment();
  const active = slug === segment;
  return <Link href={`/blog/${slug}`} aria-current={active ? "page" : undefined}>{slug}</Link>;
}

Visit the blog post whose slug is "react-19", and this component's link for that same slug receives an aria-current value of "page" while any other link does not, since the hook returns "react-19" as the active segment at that point in the route tree. Screen readers announce that value, and it gives you a reliable hook for styling the active state visually as well.

Where this hook has to be called

This is a Client Component hook, so a layout, which is a Server Component by default, cannot call it directly. Import a small client component like the one above into the layout instead, and let that component call the hook on the layout's behalf.

App.tsx

// app/blog/layout.tsx
import BlogNavLink from "./blog-nav-link";
export default function BlogLayout({ children }: { children: React.ReactNode }) {
  return (
    <>
      <nav><BlogNavLink slug="react-19" /></nav>
      {children}
    </>
  );
}

Add one more BlogNavLink for every tab the nav should show, each with its own slug value. The layout itself stays a Server Component, and only the small piece that actually needs to read navigation state opts into the client, which keeps the rest of the page's rendering on the server instead of shipping more JavaScript than the nav actually needs.

The plural version, and when to use it

useSelectedLayoutSegments returns an array covering every segment below the layout, instead of a single string one level down. The table below summarizes the difference.

Reach for the plural hook when building breadcrumbs across nested segments, since it gives you the full chain in one call. Reach for the singular hook for a flat set of tabs at a single level, which is the more common case for a section nav.

When usePathname is simpler

Neither hook can see segments above the layout that calls it, only what is nested below. For a flat nav with no meaningful layout nesting to take advantage of, comparing the full path with usePathname is often more direct than reading a single segment and reconstructing the path yourself. See usePathname and useSearchParams Explained for that approach, and How to Share UI Across Pages with Nested Layouts for where a nav component like this one typically lives inside a project.