# HTTP Session

> Learn what HTTP sessions are and how they maintain state across stateless HTTP requests. Understand session cookies, tokens, and server-side storage.

Source: https://howhttpworks.com/glossary/session
Last reviewed: 2026-10-05

> **TL;DR:** A web session associates independent HTTP requests with application state, often through an opaque ID in a cookie. Cookie lifetime and server-side session lifetime are separate; closing a browser is not reliable logout.

## Why Sessions Exist

HTTP does not automatically associate two requests with the same logged-in account. An application adds that association. A server-side session can hold a user ID or cart while the browser carries only an identifier. HTTP connection reuse is not a login session.

For a multi-step form, the record can hold a draft ID while each page submits the same cookie. Verify ownership again when saving the draft; knowing its ID or finding it in a session does not replace the application's access checks.

## How Sessions Usually Work

After authenticating, the server creates a session record and sets a cookie. Illustrative header, where `opaque-session-id` stands for a randomly generated value:

```http
Set-Cookie: __Host-session=opaque-session-id; Path=/; Secure; HttpOnly; SameSite=Lax
```

A later eligible request carries:

```http
Cookie: __Host-session=opaque-session-id
```

The browser does not echo `Secure`, `Path`, or `SameSite` in Cookie. The server uses the ID to find state and checks whether that session is still valid.

## The Important Distinction

“Session cookie” means a cookie without `Expires` or `Max-Age`, not necessarily a cookie containing a session ID. An authentication cookie can be persistent; a session cookie can hold a preference instead. Browser session restoration can restore session cookies after a restart.

Sessions can also keep state in a signed cookie or token. Server-side storage is a common implementation, not the definition of every session. The [Set-Cookie reference](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie) explains cookie lifetime and prefix rules.

## Why Session Bugs Feel Weird

If login disappears on the next request, first check whether the response set a cookie and whether the next request sent it. Then check domain, path, Secure, SameSite, and the server-side record. Cross-origin Fetch needs `credentials: 'include'` for cookies, plus appropriate CORS permission. Cross-origin and cross-site are different tests.

A load-balanced application can send a valid ID to a server that cannot find the record if its session store is process-local.

## Security Matters Here

Secure restricts transport to secure connections; HttpOnly prevents direct JavaScript access to the cookie. It does not stop injected scripts from making authenticated requests. Rotate the session ID after authentication and enforce expiration and logout in the server-side store.

[RFC 6265bis](https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/) remains work in progress in the RFC Editor queue as of this review; do not present its draft number as a published RFC.

## Related

- [Sessions and state](https://howhttpworks.com/guides/sessions-and-state)
- [Set-Cookie](https://howhttpworks.com/headers/set-cookie)