Next.js `params` vs `searchParams`: How to Read URL Parameters

Next.js params and searchParams both describe the current URL, but they capture two different parts of it. The params prop holds values from the folder path itself, while the searchParams prop holds values from the query string after the question mark.

text

/products/running-shoes?sort=price&order=asc
          ------------- ---------------------
          params.slug    searchParams

For a route file at app/products/[slug]/page.tsx, this single URL fills params with the product slug and searchParams with the sort options. Neither prop overlaps with the other.

Where params comes from

A page only receives params when its route has a bracketed folder somewhere in the path. The value comes entirely from the URL's path segments, not from anything after the question mark.

App.tsx

// app/products/[slug]/page.tsx
export default async function Page({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  return <h1>{slug}</h1>;
}

Visiting /products/running-shoes resolves slug to "running-shoes", regardless of any query string appended to the same URL.

Where searchParams comes from

The searchParams prop holds everything after the question mark, parsed into a plain object. It exists on every page, even one with no dynamic segments in its path at all.

App.tsx

// app/products/[slug]/page.tsx
export default async function Page({
  searchParams,
}: {
  searchParams: Promise<{ sort?: string }>;
}) {
  const { sort } = await searchParams;
  return <p>Sort: {sort ?? "default"}</p>;
}

Requesting the running shoes page with a sort value of price renders "Sort: price". Leaving off the query string renders "Sort: default" because of the nullish fallback.

Side by side

Both are request-dependent data, so a layout never receives searchParams even though it can receive params. That rule is covered in more depth in page.js props, params, and search params.

Reading both together

A page can accept both props at once, which is common on a product listing that is both dynamic and filterable.

App.tsx

// app/products/[slug]/page.tsx
type Props = {
  params: Promise<{ slug: string }>;
  searchParams: Promise<{ sort?: string }>;
};
 
export default async function Page({ params, searchParams }: Props) {
  const { slug } = await params;
  const { sort } = await searchParams;
  return <p>{slug} sorted by {sort ?? "default"}</p>;
}

Awaiting each prop separately keeps the two sources of data clearly labeled in the code, which matters once a page reads several dynamic segments alongside several query values. For the fully worked-out dynamic segment example on its own, see dynamic routes in Next.js.

Common mistake

Mixing up the two names is the most common mistake, especially when a route has both a dynamic segment and query filters. If a value is missing where you expect it, check whether it actually lives in the path or in the query string, since reading the wrong prop returns undefined instead of an error.

A second mistake is reaching for params when the value should really change without a page reload, such as a sort order a visitor toggles repeatedly. Because params comes from the folder structure, changing it means navigating to a different URL entirely, while a searchParams value can update in place through a link or a router call. Choosing the wrong one early tends to force a larger rewrite later, so decide up front whether a value identifies a resource or merely adjusts how it is displayed.