Routing in Clerk
Some of Clerk's components have their own internal routing.
For example, say a user uses their email address to fill out the <SignUp /> form. Once they submit the form, they are redirected from /sign-up to /sign-up/verify-email-address, which renders Clerk's UI for verifying a user's email address. This redirect is handled by Clerk's internal routing.
routing prop
The following Clerk components accept a routing prop in order to define the routing strategy:
There are three routing strategies that can be passed:
Out of the box, Clerk will attempt to select the routing strategy that best integrates with your framework of choice. If for some reason the default routing strategy doesn't work for you, use the information below to pick a strategy that will work for your setup.
path routing
path routing uses the path in the URL to determine the route. This is useful for server-rendered pages where SEO and server-side routing are crucial, such as Next.js or Remix applications.
For example, say you have a Clerk + Next.js application with the <SignUp /> component on a dedicated /sign-up page. A user visit this page and uses their email address to fill out the <SignUp /> form. Once they submit the form, they are redirected from /sign-up to /sign-up/verify-email-address.
In Clerk applications that use the Next.js or Remix SDKs, path routing is set by default on all Clerk components, as these frameworks support server-side routing out-of-the-box. There is no need to pass the routing or path props to Clerk components in these frameworks.
hash routing
hash routing uses the hash (#) portion of the URL to determine the route. This is useful for single-page applications that use client-side routing.
For example, say you have a Clerk + React application with the <SignUp /> component on a dedicated /sign-up page. A user visit this page and uses their email address to fill out the <SignUp /> form. Once they submit the form, they are redirected from /sign-up to /sign-up#verify-email-address.
In Clerk applications that use any SDK other than Next.js or Remix, hash routing is set by default on all Clerk components.
virtual routing
virtual routing uses a memory router to determine the route. A memory router manages its own history stack in memory instead of using any part of the URL. This is useful for modals and other UI components that don't need to change the URL. This option is considered experimental.
For example, say you have a Clerk + Next.js application with the <UserButton /> component. When a user selects the <UserButton /> and selects Manage account, a modal appears with the user's account information. The modal does not change the URL, but it does change the UI. You can navigate between both the tabs of the modal, Profile and Security, and initiate flows within the modal, such as adding a new email address, all without changing the URL.