{"id":548734,"date":"2026-07-17T13:38:05","date_gmt":"2026-07-17T13:38:05","guid":{"rendered":"https:\/\/webkul.com\/blog\/?p=548734"},"modified":"2026-07-18T06:20:58","modified_gmt":"2026-07-18T06:20:58","slug":"handling-sessions-and-cookies-in-next-js","status":"publish","type":"post","link":"https:\/\/webkul.com\/blog\/handling-sessions-and-cookies-in-next-js\/","title":{"rendered":"Handling Sessions and Cookies in Next.js"},"content":{"rendered":"\n

Almost every web application needs to remember its users. Once someone logs in, they expect to stay signed in while moving between pages.<\/p>\n\n\n\n

Cookies and sessions make this possible. They work together to maintain a user’s login state and provide a seamless authentication experience.<\/p>\n\n\n\n

Next.js offers a simple server-side API for working with cookies in the App Router, making it an essential part of modern Next.js development<\/a> for building secure, scalable, and dynamic web applications.<\/p>\n\n\n\n

You can also use middleware to verify authentication and protect routes before a request reaches your application. For a deeper understanding, read Next.js Auth Using Middleware.<\/a><\/p>\n\n\n\n

In this guide, you’ll learn how cookies work, how to build a simple session, and how to keep it secure.<\/p>\n\n\n\n

\"session<\/figure>\n\n\n\n

Cookies vs. Sessions<\/strong><\/h2>\n\n\n\n

Cookies and sessions are closely related, but they serve different purposes.<\/p>\n\n\n\n

A cookie is a small piece of data stored in the browser. The browser automatically sends it with every request to your application.<\/p>\n\n\n\n

A session represents a user’s authenticated state. In most applications, the browser stores a session token or ID in a cookie, allowing the server to identify the user on future requests.<\/p>\n\n\n\n

There are two common ways to manage sessions. You can store the session data directly in a cookie (stateless sessions) or store only a session ID in the cookie while keeping the session data on the server (stateful sessions).<\/p>\n\n\n\n

We’ll start with the stateless approach because it’s simple and easy to implement.<\/p>\n\n\n\n

The cookies()<\/code> API<\/strong><\/h2>\n\n\n\n

Next.js provides the cookies()<\/code> API through next\/headers<\/code> for reading and writing cookies on the server.<\/p>\n\n\n\n

Starting with Next.js 15, cookies()<\/code> is asynchronous, so you need to await<\/code> it before accessing cookie values.<\/p>\n\n\n\n

Here’s how you read a cookie value.<\/p>\n\n\n\n

import { cookies } from "next\/headers";\n\nconst cookieStore = await cookies();\nconst theme = cookieStore.get("theme")?.value;<\/pre>\n\n\n\n
You can set and delete cookies too.<\/p>\n\n\n\n
cookieStore.set("theme", "dark");\ncookieStore.delete("theme");<\/pre>\n\n\n\n
Where You Can Set Cookies<\/strong><\/h3>\n\n\n\n
Reading cookies is supported in most server-side environments.<\/p>\n\n\n\n
Writing or deleting cookies, however, is only allowed where Next.js can modify the response.<\/p>\n\n\n\n
That means you can set cookies inside Server Actions<\/strong>, Route Handlers<\/strong>, and Middleware<\/strong>.<\/p>\n\n\n\n
You cannot set cookies inside a Server Component<\/strong> because the response may have already started streaming to the browser.<\/p>\n\n\n\n
If you need to update a cookie from a page, move that logic into a Server Action instead.<\/p>\n\n\n\n
Keeping Cookies Secure<\/strong><\/h3>\n\n\n\n
Cookie attributes play an important role in protecting user sessions.<\/p>\n\n\n\n
A secure session cookie usually looks like this:<\/p>\n\n\n\n
cookieStore.set("session", token, {\nhttpOnly: true,\nsecure: true,\nsameSite: "lax",\npath: "\/",\nmaxAge: 60 * 60 * 24 * 7, \/\/ 7 days\n});<\/pre>\n\n\n\n
Building a Simple Session<\/strong><\/h2>\n\n\n\n
Let’s build a simple stateless session using JWT.<\/p>\n\n\n\n
We’ll use the jose<\/code> library because it works in both the Node.js and Edge runtimes.<\/p>\n\n\n\n
npm install jose<\/pre>\n\n\n\n
Now create two helper functions to sign and verify session tokens.<\/p>\n\n\n\n
\/\/ lib\/session.ts\n\nimport "server-only";\nimport { SignJWT, jwtVerify } from "jose";\nconst key = new TextEncoder().encode(process.env.SESSION_SECRET);\nexport async function encrypt(payload: { userId: string; email: string }) {\nreturn new SignJWT(payload)\n.setProtectedHeader({ alg: "HS256" })\n.setExpirationTime("7d")\n.sign(key);\n}\n\nexport async function decrypt(token?: string) {\nif (!token) return null;\ntry {\nconst { payload } = await jwtVerify(token, key);\nreturn payload as { userId: string; email: string };\n} catch {\nreturn null;\n}\n}<\/pre>\n\n\n\n
encrypt()<\/code> creates a signed token, while decrypt()<\/code> verifies the token and returns its payload.<\/p>\n\n\n\n
Creating the Session<\/h3>\n\n\n\n
After a user signs in successfully, create a session cookie.<\/p>\n\n\n\n
\/\/ app\/actions\/session.ts\n\n"use server";\n\nimport { cookies } from "next\/headers";\nimport { encrypt } from "@\/lib\/session";\nexport async function createSession(userId: string, email: string) {\nconst token = await encrypt({ userId, email });\n(await cookies()).set("session", token, {\nhttpOnly: true,\nsecure: process.env.NODE_ENV === "production",\nsameSite: "lax",\npath: "\/",\nmaxAge: 60 * 60 * 24 * 7,\n\n});\n\n}<\/pre>\n\n\n\n
This signs the user’s data and saves it as a session cookie.<\/p>\n\n\n\n
Reading the Session<\/strong><\/h2>\n\n\n\n
Create a helper to read and verify the session anywhere on the server.<\/p>\n\n\n\n
\/\/ lib\/get-current-user.ts\n\nimport { cookies } from "next\/headers";\nimport { decrypt } from "@\/lib\/session";\nexport async function getCurrentUser() {\nconst token = (await cookies()).get("session")?.value;\nreturn decrypt(token);\n}<\/pre>\n\n\n\n
If the session is valid, this function returns the authenticated user. Otherwise, it returns null<\/code>.<\/p>\n\n\n\n
You can now protect any page.<\/p>\n\n\n\n
\/\/ app\/dashboard\/page.tsx\n\nimport { getCurrentUser } from "@\/lib\/get-current-user";\nimport { redirect } from "next\/navigation";\nexport default async function Dashboard() {\nconst user = await getCurrentUser();\nif (!user) redirect("\/login");\nreturn <h1>Welcome back, {user.email}<\/h1>;\n\n}<\/pre>\n\n\n\n
If no valid session exists, the user is redirected to the login page.<\/p>\n\n\n\n
Refreshing Sessions with Middleware<\/strong><\/h3>\n\n\n\n
Middleware runs before a request reaches your application, making it a great place to validate or refresh user sessions.<\/p>\n\n\n\n
If you’d like to learn more about protecting routes with middleware, check out Next.js Auth Using Middleware<\/strong>.<\/p>\n\n\n\n
import { NextResponse, type NextRequest } from "next\/server";\nimport { decrypt } from "@\/lib\/session";\n\nexport async function middleware(req: NextRequest) {\nconst token = req.cookies.get("session")?.value;\nconst session = await decrypt(token);\nif (!session) {\nreturn NextResponse.redirect(new URL("\/login", req.url));\n}\nreturn NextResponse.next();\n}\nexport const config = { matcher: ["\/dashboard\/:path*"] }<\/pre>\n\n\n\n
This checks the session on protected routes and redirects if it’s missing.<\/p>\n\n\n\n
Stateless vs. Stateful Sessions<\/strong><\/h3>\n\n\n\n
The approach used above is called a stateless session<\/strong> because the session data is stored inside the token. It’s simple to implement and doesn’t require a database. The downside is that you can’t revoke a token until it expires.<\/p>\n\n\n\n
A stateful session<\/strong> stores only a session ID in the cookie while keeping the actual session data on the server.This allows features like instant logout, session revocation, and device management.<\/p>\n\n\n\n
Choose stateless sessions for simplicity. Switch to stateful sessions when your application requires more control.<\/p>\n\n\n\n
Security Checklist<\/strong><\/h2>\n\n\n\n
Follow these best practices to keep session cookies secure.<\/p>\n\n\n\n