The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Cookies, sessions, and JWTs are not three competing ways to log someone in. They sit at different layers. A cookie is a browser storage and transport mechanism, a session is application state, and a JWT is a token format. Because they answer different questions, they are often combined: a server can keep session state and give the browser an identifier in a cookie, or it can send a JWT in a cookie, or it can send a JWT through some other channel.
What each term means
Cookie
A cookie is data that a server asks a browser (or other user agent) to store, and that the browser then returns to the server in later requests that match the cookie’s rules. The mechanism is defined in RFC 6265, “HTTP State Management Mechanism,” published by the IETF in April 2011. The server sends a Set-Cookie response header; the browser sends the stored values back in a Cookie request header.
As an Amazon Associate I earn from qualifying purchases.
A cookie does not, by itself, mean someone is logged in. It is a way to store and return a small value. Whether that value means anything about authentication depends entirely on what the application puts in it.
Session
A session is application-level state associated with a user or client across multiple requests: which user is signed in, what is in a shopping cart, which step of a wizard the user reached. The session is a concept in your application, not an HTTP header.
#1 Best Overall
The most common arrangement is server-managed. The server creates a record, stores its data server-side, and gives the client an opaque identifier. RFC 6265 describes this pattern: the server stores a nonce or session identifier in a cookie and uses it as a key to retrieve the associated state. That is why the words “cookie” and “session” show up together so often. The cookie carries the pointer; the session is the data behind it.
JWT (JSON Web Token)
A JSON Web Token is a compact, URL-safe way to represent a set of claims, such as a user identifier and an expiry time. RFC 7519, published by the IETF in May 2015, defines the format. A JWT can be integrity-protected (signed, or protected with a message authentication code) or encrypted. These are separate properties:
Rank #2
- HTML CSS Design and Build Web Sites
- Comes with secure packaging
- It can be a gift option
- Signed or MAC-protected means a recipient can detect whether the token was altered. It does not mean the contents are hidden. Anyone holding a signed JWT can usually decode its payload, because the payload is encoded, not encrypted.
- Encrypted means the contents are unreadable without the key. This is a different property from integrity.
JWT is a format. It does not say where the token is stored, how it is sent, how long it lasts, or how it is revoked. Those decisions belong to the application.
How the three layers compare
The table below sets the layers side by side. The question is not which one wins, but which layer each design decision belongs to.
Rank #3
| Question | Cookie | Server-managed session | JWT |
|---|---|---|---|
| What it is | Storage and HTTP request/response mechanism in the user agent | Application state, usually kept on the server | A compact, URL-safe representation of claims |
| Where the data lives | The cookie value and attributes are held by the browser; the server receives applicable values | Usually on the server; the client holds an identifier that points to it | Inside the token itself; where the token is stored is an implementation choice |
| How it reaches the server | Browser attaches matching cookies to requests automatically | Often as a session ID inside a cookie | Whatever transport the application chooses; the format does not require a cookie |
| Can it be invalidated on the server? | Expiry controls how long the browser keeps the cookie, not whether the credential it carries is still valid | Yes, by changing or deleting the server-side record; exact behavior depends on the implementation | Not specified by the format; any revocation mechanism is an application design |
| Main security concerns | Attributes such as HttpOnly, Secure, and SameSite; automatic sending that enables CSRF | Protecting the session identifier and managing its lifecycle | Distinguishing integrity from confidentiality; a stolen token is usable until it expires or is otherwise rejected |
Common ways they combine
Server-side session with a cookie holding the session ID
The server creates a session record when a user signs in and sends a cookie containing only an opaque identifier. Each later request carries that cookie; the server looks up the record and checks its state. Because the record is server-side, the server can end the session by deleting or marking it. The trade-off is that every request depends on the server, or a shared store, being able to find that record.
JWT carried in a cookie
The server signs a token containing claims and places it in a cookie. The browser then sends it automatically, the same way it sends a session identifier. This keeps the browser-side mechanics of a cookie, but the state lives in the token. The server can verify the signature without a session lookup, yet it still needs a rule for tokens that should no longer be accepted, since the format alone does not provide one.
Rank #4
- Brand: Wiley
- Set of 2 Volumes
- A handy two-book set that uniquely combines related technologies Highly visual format and accessible language makes these books highly effective learning tools Perfect for beginning web designers and front-end developers
JWT sent in a request header
The application can send the token in a header that its client code sets explicitly. Because the browser does not attach a header automatically, this approach does not carry the same ambient-sending exposure as a cookie. It shifts the question to how client code stores the token and whether scripts on the page can read it, which is a separate browser-security decision. Storing a token where JavaScript can read it removes the protection that HttpOnly cookies provide.
Cookie settings that affect security
When a cookie carries authentication data, its attributes matter as much as the choice of design. MDN’s guidance on secure cookie configuration covers three attributes. They protect against different risks and are independent of each other.
- Secure limits transmission of the cookie to secure (HTTPS) connections.
- HttpOnly limits access to the cookie through non-HTTP APIs, which means JavaScript on the page cannot read it. MDN recommends cookies for browser session management where possible because of this protection. This is guidance for browser-based applications, not a universal verdict for every client or architecture.
- SameSite controls whether the browser sends the cookie on cross-site requests.
A typical sign-in cookie might look like this:
Set-Cookie: session_id=4f9c2a7e; Path=/; Secure; HttpOnly; SameSite=Lax
HttpOnly does not prevent cross-site request forgery. Because browsers attach cookies automatically, a page on another site can cause a victim’s browser to send an authenticated request. RFC 6265 discusses these pitfalls. Defenses such as SameSite, anti-CSRF tokens, or checks on the request’s origin are needed in addition to HttpOnly.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What the formats do not decide
- Performance and scale. The standards define mechanisms. They do not establish that JWTs are faster, or that sessions scale worse, in any particular deployment. Those outcomes depend on the architecture.
- Revocation. A server-side session can be ended by changing server state. A self-contained JWT stays valid until its expiry unless the application checks an additional list or uses a shorter lifetime. RFC 7519 does not define that behavior.
- Safety by default. A JWT that is signed but not encrypted can be read by whoever holds it. Moving the token into a browser does not remove browser-side credential risks.
Choosing a design
The right choice depends on the constraints of the application. These questions help narrow the decision:
- Is the client a browser? If so, a cookie with HttpOnly, Secure, and SameSite is a well-documented starting point, and CSRF defenses must be added.
- Do you need to end a user’s access immediately? Server-side session state makes that straightforward. A JWT design needs an explicit revocation or short-lifetime plan.
- Do several independent services need to verify the same credential without calling a shared session store? A signed JWT can help, provided each service validates the signature, expiry, and intended audience.
- Does the token contain data that must stay private? Use encryption, or keep sensitive values server-side and carry only an identifier.
The three concepts answer different questions, so the useful comparison is between complete designs, not between terms. Read the standards for the exact definitions, then decide which layer owns each control.
Sources: RFC 6265, “HTTP State Management Mechanism” (IETF, April 2011); RFC 7519, “JSON Web Token (JWT)” (IETF, May 2015); MDN Web Docs, “Authentication,” “Session management,” and “Secure cookie configuration.”
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.
