Using next/link for Client‑Side Navigation

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.
Link is the component for internal navigation
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 client‑side 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 app‑like
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 client‑side 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 file‑system router understands.
That keeps navigation aligned with the route layer rather than with arbitrary implementation details.
Link renders the anchor in modern Next.js
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.
Dynamic routes still work through Link
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
- screen‑reader 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
Linkto provide internal route transitions for external destinations - nesting an extra anchor inside
Linkon Next.js 13 or later - treating
Linkas 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.