· By John Kavanagh

Using next/link for Client‑Side Navigation

Abstract image used to represent Using next/link for Client‑Side Navigation
Image by Getty Images.

One of the first habits developers need to unlearn when moving into Next.js is treating every internal link like a plain old HTML anchor.

An ordinary anchor works perfectly well in the browser:

<a href="/about">About</a>

The trouble is that in a Next.js application, internal navigation can do more than a full page reload. It can stay on the client, preserve application state more gracefully, and feel noticeably faster. That is what next/link is for.


When navigating between pages inside a Next.js application, we use the Link component:

import Link from 'next/link';

const Navigation = (): JSX.Element => {
  return (
    <nav>
      <Link href="/about">About</Link>
    </nav>
  );
};

That tells Next.js this is an internal route transition, not just a generic browser navigation.


Why Not Just Use a Normal Anchor

Because internal links in Next.js can be smarter.

Link enables clientside navigation, which means the framework can:

  • avoid a full document reload
  • reuse the application shell more smoothly
  • prefetch route resources in some cases
  • make navigation feel faster and more applike

A plain anchor still works, but it gives up those benefits for internal routes.


The Difference Shows up in User Experience

With a full reload, the browser treats the destination like an entirely new page load. With clientside navigation, the route change feels lighter because the application can stay alive whilst only the page content changes.

That does not mean every navigation becomes instant, of course. Data still needs to load and rendering still takes time. But the framework has much more room to make transitions feel efficient when it knows the link is internal.

That sounds like a small detail until a project gets large enough for navigation to become part of the performance story. On the Nando’s UK & Ireland Replatform, using Next.js routing properly mattered because internal journeys had to feel quick and predictable across a much broader site.


href points to the route, not the component

This sounds obvious, but it is worth being explicit about. Link works with the route path:

<Link href="/articles">Articles</Link>

The link is not importing or targeting a component directly. It is targeting the URL that the filesystem router understands.

That keeps navigation aligned with the route layer rather than with arbitrary implementation details.


Since Next.js 13, the conventional pattern is:

<Link href="/about">About</Link>

Link renders the clickable anchor itself, so ordinary HTML link semantics are preserved whilst Next.js enhances navigation behaviour around it.

The extra nested anchor is no longer part of the normal API.


External Destinations Usually Need Only an Anchor

Choose the link according to the destination and the navigation behaviour you need.

If the destination is another page inside the same Next.js application, Link is appropriate.

If the destination is an external site, a normal anchor is usually the right tool:

<a href="https://example.com">External site</a>

Link can render an external destination, but it cannot turn that other site into an internal route transition. A plain <a> is normally sufficient for the same browser navigation.


Prefetching is One of the Quiet Advantages

Next.js can prefetch route resources for links that are likely to be visited soon, especially when they enter the viewport.

That means the user may perceive navigation as faster because some of the work has already started before they click.


Links are not limited to flat static paths. As the route structure grows, Link remains the way we connect the user to internal destinations.

In a content site, for instance, article cards can use internal links naturally:

<Link href="/articles/accessibility-basics">Accessibility basics</Link>

That keeps navigation explicit and still lets Next.js treat the transition as part of the application.


The Component Improves Routing, Not Semantics

This distinction matters because developers sometimes start thinking of Link as a replacement for accessible link behaviour. It is not.

The semantics still come from the anchor rendered by Link:

  • keyboard interaction
  • screenreader expectations
  • link meaning

Next.js is helping with routing performance and application behaviour. The underlying HTML still matters.


Common Mistakes

The same mistakes appear repeatedly:

  • using plain anchors for internal routes everywhere
  • expecting Link to provide internal route transitions for external destinations
  • nesting an extra anchor inside Link on Next.js 13 or later
  • treating Link as though it were a generic wrapper for anything clickable

Most of these come from not separating "navigation within the app" from "ordinary hyperlinks in general".


Wrapping Up

Use next/link for navigation within the application, keep the href tied to a real route and give each link a useful label. Check keyboard navigation and the destination page as well as how quickly the transition feels.

Postscript

July 2026: Next.js changed this API in version 13: Link now renders its own anchor, so the nested <a> pattern used by the original 2018 article is invalid in current releases. I have updated the examples to match the current Pages Router documentation; older projects should follow the migration guidance rather than carrying the extra anchor into new code.

Have a complex web platform issue?

Tell me what is blocked, what has changed, and what needs to be true after the fix. I'll come back with a practical next step.