Fix Next.js "params should be awaited" Error in Next.js 15+ If you are seeing the params should be awaited Next.js error after upgrading to Next.js 15 or following an older App Router tutorial, you are not alone.
The error usually looks something like this: Sometimes it appears with .
Sometimes it appears with or .
And sometimes the page still seems to work, but your terminal keeps shouting at you.
This article will slow it down and explain the fix in a beginner-friendly way.
No deep framework lecture first.
Just the actual problem, the broken code, the fixed code, and the reason it works.
What This Error Means in Plain English In older Next.js code, you may have treated like a normal JavaScript object.
Something like this: That used to feel natural.
If your route was: and the user opened: you expected: In newer Next.js versions, especially Next.js 15+, some request-based values became asynchronous.
That means you should treat them like values that need to be waited for before you read from them.
So instead of reading directly, you do this: That is the heart of the fix.
The error is not saying your route is missing.
It is not saying your folder is wrong.
It is saying: You are trying to read route data before awaiting it.
The common flow: the page loads, the code reads directly, Next.js expects to be awaited, and the error appears.
Why This Changed Next.js has a group of features called Dynamic APIs.
That sounds more complicated than it is.
In simple terms, Dynamic APIs are values that depend on the current request.
For example: What route did the user open?
What query string is in the URL?
What cookies came with this request?
What headers came with this request?
Is draft mode enabled?
Those values are not the same for every user.
They depend on the incoming request, so Next.js treats them differently from static code.
In Next.js 15+, these Dynamic APIs are asynchronous: That is why old examples from Next.js 13 or 14 can suddenly throw warnings or errors after an upgrade.
The same async idea applies to more than just .
If it depends on the request, check whether it needs .
The Broken Dynamic Route Example Let's start with the most common case: a blog post page.
You have this route: The part means the route is dynamic.
So these URLs can all use the same file: In older tutorials, you may see code like this: This is the broken pattern in Next.js 15+.
The problem is this line: You are reading directly from .
But Next.js expects you to wait for first.
The Fixed Dynamic Route Example Here is the fixed version: Two things changed: The component became .
We used before reading .
That is it.
Small code change, big difference.
Before: read directly.
After: make the function , await , then read .
Why Adding Matters This part is important for beginners.
You cannot use inside a normal function.
This will not work: JavaScript will complain because needs an function.
So you need this: Think of as telling JavaScript: This function may need to wait for something.
And means: Wait here until this value is ready, then continue.
So the pattern is: Do Not Await This is a very common mistake.
You might try this: That looks close, but it is not the right fix.
You are still trying to access before awaiting .
The correct order is: Wait for the whole object first.
Then read .
Fixing This error often appears on blog sites because the page is not the only place where you read .
You may also use inside .
For example, this is broken: The fixed version is: This matters because a lot of developers fix , refresh the app, and still see the same warning.
Then they feel stuck.
The reason is simple: The same broken access may also exist in .
So when you fix a dynamic route, search the whole file for: Do not only check the page component.
Fixing Now let's talk about . usually comes from the path.
Example: comes from the query string.
Example: In older code, you might write: In Next.js 15+, use the async pattern: The idea is the same.
Do not read from first.
Await it first.
Then read from it.
Fixing Both and Together Sometimes a page needs both.
Example: Your route might be: Here is the fixed version: You can await them separately.
That keeps the code easy to read.
Fixing The same migration affects from .
Here is the broken version: The fixed version: Again, the order matters.
Do not do this: Do this: You wait for the cookie store first.
Then you read from it.
Fixing follows the same idea.
Broken: Fixed: If you remember the cookie example, this should feel familiar.
Await the store.
Then read from the store.
Route Handler Example This error can also show up in route handlers.
For example: Broken: Fixed: The file is different, but the fix is the same.
If the handler receives , await it before reading , , or any other dynamic value.
TypeScript Version If you use TypeScript, update the type too.
Broken: Fixed: This is where many build errors come from.
The code may look logically correct, but the type still says is a plain object.
In Next.js 15+, type it like a Promise when you are using this async pattern.
The Codemod Can Help Next.js provides a codemod for this migration.
A codemod is a script that updates code automatically.
You can run: This can update many , , , and usages for you.
But do not run it and assume everything is perfect.
After the codemod, review the changed files.
Pay extra attention to: custom TypeScript types helper functions auth utilities Supabase or other server clients route handlers The codemod is useful, but your app still needs a human review.
Common Mistakes Mistake 1: Awaiting the Property Instead of Avoid this: Use this: Await the object first.
Then read the property.
Mistake 2: Forgetting Avoid this: Use this: If there is , the function needs .
Mistake 3: Fixing the Page but Forgetting Metadata You may fix this: But forget this: If the warning still appears, search the file for: Mistake 4: Copying Old Tutorial Code This one is common.
You follow a tutorial.
The tutorial uses: Your app uses Next.js 15 or newer.
Now you get an error.
That does not mean the tutorial is completely useless.
It may just be written for an older version of Next.js.
Update the request-data parts to the newer async pattern.
Mistake 5: Thinking the Route Folder Is Wrong When beginners see this error, they sometimes rename folders or move files around.
Usually, that is not needed.
If your route is: that folder structure is fine.
The issue is usually inside the code: not the route folder itself.
Beginner Debugging Checklist Use this when the error will not go away.
A quick checklist for finding the common places where this error hides.
Ask these questions: Is this a dynamic route like , , or ?
Am I reading , , or another property directly?
Did I make the function ?
Did I use ?
Did I also check ?
Am I using ?
Am I using or ?
Do my TypeScript types say is a Promise?
Did I run the codemod and review the result?
Most of the time, one of these checks will reveal the issue.
Quick Fix Cheatsheet Here are the patterns to remember.
For : For : For : For : For TypeScript: How This Relates to Other Next.js Bugs This error is part of a bigger pattern in Next.js.
Some bugs happen because code runs in a different place than you expected.
For example, in my previous article on fixing Next.js hydration errors with localStorage, the problem was server HTML not matching the first client render: In the middleware redirect loop article, the problem was request flow: This article is also about flow.
But this time, the flow is about when request data is ready: Once you see it that way, the error becomes much less scary.
Final Takeaway The Next.js params should be awaited error usually means you are reading request-based data too early.
In older code, this looked normal: In Next.js 15+, use this: And remember the simple rule: Treat route and request data as async.
Await it first, then read from it.
That rule applies to: If you are upgrading a project, run the codemod, then review your dynamic routes, metadata fun