url is considered as new if only a hash was changed from previous url

[waqas2714]

For Contributors

Fixing a bug

• Related issues linked using fixes #88986
• Tests added: test/e2e/app-dir/hash-navigation
• Errors have a helpful link attached

For Maintainers

What?

Fixes hash navigation when using next/link so that clicking a link to the same hash (e.g. #section) triggers scrolling again.

Previously, if the current URL already contained the same hash, Next.js treated it as a no-op and did not scroll.

---

Why?

This breaks expected browser behavior and real user flows:

• Users scroll away from a section
• Click the same in-page link again
• Nothing happens

Native anchors scroll again, but Next’s router skipped navigation due to the onlyAHashChange logic.

This affects common patterns such as:

• Table of contents links
• In-page navigation menus
• Documentation pages

---

How?

The router logic was updated so that same-hash navigations are no longer ignored.

Instead of treating identical hash changes as a no-op, the router now explicitly allows the navigation, ensuring scroll behavior is applied again.

---

Closes NEXT-
Fixes #88986

[nextjs-bot]

Allow CI Workflow Run

• approve CI run for commit: 918dd35

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

[timneutkens]

PR looks incorrect. The test is checking App Router but the change is in the router for Pages Router, so won't work.

[vercel]

Suggested change

if (this.onlyAHashChange(asPath)) return true

The urlIsNew method incorrectly returns true when navigating to the same URL with the same hash, causing duplicate browser history entries.

[waqas2714]

Hi @timneutkens . I made the change in base router. Should it not affect both app and page router? Also, the issue was created for the app router hence the test case for app router. Sorry for any inconvenience, I am new to open source.

Thanks!