iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To fix the Next.js “params should be awaited” error, stop reading route parameters as a plain object. In Server Components and Route Handlers, make the function async and await params before accessing its fields. In a synchronous Client Component, unwrap it with React’s use(). Then check every App Router entry point and related API—not just the first line named in the error.
Why Next.js says params should be awaited
Starting in Next.js 15, request-time APIs that depend on the incoming request became asynchronous. That includes params passed to pages, layouts, and Route Handlers, as well as page searchParams. A direct read such as params.slug treats the Promise like the old synchronous object and triggers the warning or error. Destructuring before awaiting, spreading the object, enumerating its keys, or passing it to a helper that immediately inspects it can cause the same problem. The Next.js error guidance describes the rule: “In Next 15, these APIs have been made asynchronous.” Next.js: Dynamic APIs are Asynchronous.
The exact behavior depends on the release and configuration. Next.js 15 temporarily allowed synchronous access for migration compatibility, but deprecated it; with cacheComponents enabled, synchronous access is an error. Next.js 16 removes synchronous access. Use the asynchronous form even if an older Next.js 15 project still appears to accept the old code. Next.js 15 upgrade guide · Next.js 16 upgrade guide.
Free tools Windows power users keep installed
One-click scans. No signup required.
Choose the right fix for the component
| Where the code runs | Use this pattern | When it fits |
|---|---|---|
| Server Component or Route Handler | await params |
The function can be declared async; this is the standard choice for server code. |
| Synchronous Client Component | use(params) |
The component must remain synchronous; import use from React and unwrap before reading fields. |
Both patterns are supported by the official Next.js error reference. The request value is still asynchronous in a Client Component; use() reads the Promise rather than turning it into a plain synchronous prop.
#1 Best Overall
Server Component: await before accessing fields
For a dynamic route such as app/blog/[slug]/page.tsx, type params as a Promise and await it before reading slug:
export default async function Page({ params }: { params: Promise<{ slug: string }> }) {
const { slug } = await params
return <h1>{slug}</h1>
}
Do not destructure in the function signature, spread params, or call params.slug before the await. If a helper needs the route fields, pass it the resolved object or await within the helper rather than letting it inspect the Promise as though it were a plain object.
Rank #2
Synchronous Client Component: unwrap with React use()
If the component has a 'use client' directive and needs to remain synchronous, unwrap the Promise with React’s use function:
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →'use client'
import { use } from 'react'
export default function Page({ params }: { params: Promise<{ slug: string }> }) {
const { slug } = use(params)
return <h1>{slug}</h1>
}
Call use(params) before using any parameter field. Do not make a Client Component async just to use await; use the documented React pattern when it must stay synchronous.
Rank #3
Find every synchronous access, not only the reported one
The first stack frame may not identify every affected call site. Search the App Router project for direct property reads, destructuring, enumeration, and helper functions that receive the unresolved Promise. Also inspect re-exported route components: the exported Page can be defined in a different file from the route entry point. The official error reference specifically notes that a Page component may be defined elsewhere.
- Look for
params.id,params.slug, and similar property reads. - Check destructuring such as
const { id } = paramsbefore an await oruse(). - Check object spread,
Object.keys(params), and loops that enumerate or iterate over the value. - Follow calls into helpers that receive
paramsand immediately inspect it. - Check pages, layouts, Route Handlers, metadata and viewport functions, default files, and special image or icon routes.
The change is broader than page bodies: the Next.js 15 upgrade guide covers asynchronous request APIs, and the Route Handler reference documents Promise-based route context.
Update route types and generated helpers
Change old plain-object declarations to Promise-based types, for example Promise<{ slug: string }>. Next.js also provides generated route helpers such as PageProps, LayoutProps, and RouteContext so route-specific parameter types can be checked without duplicating them by hand. PageProps is generated during next dev or next build, and can also be generated explicitly with next typegen. See the Page reference and Route Handler reference for the applicable signatures and helpers.
Run the codemod, then resolve its review markers
The official codemod can migrate many request API call sites, but it does not guarantee that every case is fixed. From the project root, run:
npx @next/codemod@latest next-async-request-api .
Review the diff and search for @next-codemod-error. The codemod may leave a comment or typecast where it cannot safely convert an expression or infer the component’s route role. Resolve each marker manually; the documentation says unresolved @next-codemod-error comments cause development or build to fail. Change the prefix to @next-codemod-ignore only when the marked code genuinely needs no action. Instructions and migration details are in the Next.js codemod guide and async request API error guide.
Check metadata, search parameters, and special route files
Do not stop after fixing the page component. Migrate all request-dependent entry points that your project uses:
generateMetadataandgenerateViewportfunctions that receive route parameters.- Route Handlers, whose context supplies
paramsas a Promise. - Layouts, default files, and special image or icon route files identified in the upgrade guide.
- Page
searchParams, which is also asynchronous and must be awaited before its fields are read.
Follow the relevant signatures in the version 15 upgrade guide, metadata reference, and page reference.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchUnderstand the rendering effect of when you unwrap
Route params are request-dependent, so accessing them makes the code that needs them depend on request-time data. Next.js notes that delaying the unwrap until the value is consumed can let more of a page be statically rendered. Page searchParams are request-time data; using them opts the page into dynamic rendering, and with Cache Components, where they are accessed affects how much can be prerendered. Place the await or use() close to the part of the UI that needs the value when that better matches the page’s rendering needs. See the page reference and async API guidance.
Version behavior at a glance
| Next.js version | Behavior | Practical guidance |
|---|---|---|
| 14 and earlier | params was synchronous. |
When upgrading, update code to the Promise-based interface. |
| 15 | Async access is the forward-compatible form; synchronous access was temporarily supported but deprecated. With cacheComponents, synchronous access is an error. |
Use await or use(); do not rely on compatibility behavior. |
| 16 | Synchronous access to request-time APIs such as params and page searchParams is removed. |
Use the async interface and generated route typing helpers where useful. |
Next.js documents the earlier synchronous behavior in the version 14 page reference, the transition in its version 15 upgrade guide, and the async-only behavior in the version 16 upgrade guide.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

