What Is a Session in Web Development? Sessions vs. Cookies Explained (With Code Examples)

Quick answer: A session is a way for a web server to remember information about a specific user across multiple requests — like keeping them logged in, or remembering what's in their shopping cart — even though the underlying HTTP protocol itself has no memory at all. HTTP is stateless by design: every request is treated as brand new, with zero awareness of any previous request. Sessions (typically paired with a cookie holding a session ID) are the mechanism developers use to work around that limitation.

This page replaces an earlier version that incorrectly suggested sessions were introduced as part of HTTP/1.0. HTTP has no native session concept — sessions exist specifically as a workaround for that limitation. Last updated August 2, 2026.

This is the detail that actually makes sessions make sense, and it's worth getting right: HTTP was never designed to remember anything. When HTTP/1.0 was published in 1996, each request-response pair was treated as a fully independent transaction — the server had no built-in way to know that a second request came from the same browser as a first one.

That's a real problem for anything resembling a modern website. Without some workaround, a shopping site couldn't remember what you added to your cart between page loads, and a login would only last for a single page view. Sessions and cookies were invented specifically to solve this — cookies were introduced by Netscape in 1994, giving browsers a small piece of storage the server could ask for on every subsequent request. Sessions build on top of that mechanism to give the server actual memory of who's making the request.

1. A user visits a website for the first time.
2. The server creates a new session and generates a unique session ID.
3. That session ID is sent to the browser, usually stored in a cookie.
4. On every subsequent request, the browser automatically sends that cookie back to the server.
5. The server uses the session ID to look up the corresponding session data — which is stored server-side, not in the cookie itself.
6. The server can then respond with content personalized to that specific user: their logged-in state, their cart contents, their preferences.

The key detail people most often get wrong: the cookie itself usually only holds the session ID — a reference — not the actual session data. The real data (login status, cart contents, etc.) lives on the server. This is exactly why sessions are considered more secure than storing sensitive data directly in a cookie.

This is the single most common point of confusion, and it's worth being precise about:

In short: cookies are the delivery mechanism (usually just carrying an ID); sessions are where the actual remembered information lives. They work together, but they are not the same thing.

• Authentication — keeping a user logged in as they navigate between pages, without re-entering credentials on every request.
• Shopping carts — remembering what a user has added, even across multiple page visits, until checkout or expiration.
• Personalization — remembering language preference, theme settings, or previously viewed content.
• Multi-step processes — like a checkout flow or a multi-page form, where information needs to persist between steps.

When people search "session based authentication explained," they're usually trying to understand how login systems actually keep you logged in. Here's the flow:

1. You submit your username and password.
2. The server verifies your credentials.
3. If valid, the server creates a session and stores your authenticated user ID against that session, server-side.
4. The server sends your browser a cookie containing the session ID.
5. On every future request, your browser sends that cookie back, and the server checks whether that session ID corresponds to a valid, authenticated session.
6. If it does, you're treated as logged in — without re-sending your password on every single page.

This is different from token-based authentication (like JWTs), where the proof of authentication is held entirely on the client rather than looked up server-side — a common point of comparison in modern web development discussions, and a reasonable next topic if you're comparing authentication approaches.

Since a session ID is effectively "proof of who you are" once you're logged in, an attacker who steals a valid session ID (through methods like cross-site scripting, network sniffing on insecure connections, or session fixation) can potentially impersonate that user without needing their actual password. This is why secure implementations use HTTPS, mark session cookies with security flags like HttpOnly and Secure, and expire sessions after a period of inactivity.

PHP (sessions are built into the language directly):

<?php
session_start(); // starts or resumes a session
$_SESSION['username'] = 'alex'; // store data in the session
echo $_SESSION['username']; // retrieve it on a later request
?>

Express (Node.js), using the express-session package:

const session = require('express-session');
app.use(session({
  secret: 'your-secret-key',
  resave: false,
  saveUninitialized: true
}));

app.get('/', (req, res) => {
  req.session.views = (req.session.views || 0) + 1;
  res.send(`You've visited this page ${req.session.views} times`);
});

Both examples show the same underlying pattern: the framework handles the cookie and session-ID bookkeeping automatically, so you just read and write to a session object as if it were a simple, persistent piece of storage per user.

If you've come across "session layer in OSI model" and are wondering how it relates to web development sessions — it's a genuinely different, unrelated concept, despite the shared name. The OSI model's Session Layer (Layer 5) is a networking-theory concept describing how connections between two devices are established, maintained, and terminated at a lower, protocol level. Web application sessions (what this article covers) are an application-level concept built by developers on top of HTTP, which itself sits at OSI Layer 7. They share terminology, not a technical relationship — don't conflate the two when studying either topic.

• "Sessions and cookies are the same thing." They're not — cookies are client-side storage, usually just holding a reference (the session ID); sessions are server-side data.
• "Sessions are only for login/authentication." They're used for a wide range of purposes, including shopping carts, personalization, and multi-step form flows.
• "HTTP has built-in session support." It doesn't — HTTP is stateless by design, and sessions are entirely a workaround built by application developers and frameworks, not a native protocol feature.