PHP Sessions and Cookies: How They Work

PHP sessions and cookies are the basic tools PHP uses to remember a visitor between requests. HTTP itself is stateless, so a browser request does not automatically know who the visitor is or what they did on the previous page.

This guide explains how sessions and cookies work, what each one is good for, and how they fit into login systems and user preferences. If you are also learning PHP security basics, this topic will connect naturally. The official PHP sessions and security manual is the best reference.

PHP sessions and cookies are not the same thing

A cookie is stored in the browser and sent with future requests. A session stores data on the server, while the browser usually keeps only the session ID cookie. That distinction matters because sessions keep sensitive state off the client, while cookies are visible to the browser.

How a session works

<?php
session_start();

$_SESSION['user_id'] = 42;

echo $_SESSION['user_id'];

The session_start() call must happen before output. After that, PHP can read and write session values for the current visitor.

How a cookie works

<?php
setcookie('theme', 'dark', [
    'expires' => time() + 60 * 60 * 24 * 30,
    'path' => '/',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);

Cookies are useful for preferences such as theme, language, or consent choices. They are less appropriate for secret or high-trust data because they live in the browser.

Use sessions for authentication state

After a user logs in, store a user ID or similar safe identifier in the session. Then check that value on protected pages. That pattern keeps authentication logic on the server and avoids exposing sensitive identifiers in the URL.

Security habits for sessions and cookies

• Call session_start() before output.
• Regenerate the session ID after login.
• Use secure, httponly, and samesite cookie flags when possible.
• Do not store passwords in cookies or sessions.
• Destroy the session properly on logout.

When to use each one

Use sessions for login state, temporary server-side workflow data, and anything that should not live in the browser. Use cookies for preferences or identifiers that can safely travel with requests. If you need to remember a visitor across visits without strong trust requirements, a cookie may be enough. If you need protected application state, use a session.

Login flow example

A typical login flow looks like this: the user submits a form, PHP checks the credentials, the server stores a user ID in the session, and the browser receives a session cookie. On the next request, the session cookie points back to the server-side session data.

That is why sessions work well for authentication. The browser only needs to carry a pointer, not the sensitive data itself. The application then checks the session on protected pages to decide whether to continue or redirect to login.

Practical cookie example

<?php
setcookie('language', 'en', [
    'expires' => time() + 60 * 60 * 24 * 365,
    'path' => '/',
    'secure' => true,
    'httponly' => false,
    'samesite' => 'Lax',
]);

This kind of cookie is fine for a language preference because it is not secret. A login cookie or session identifier needs stricter handling than a display preference.

Destroy sessions properly on logout

Logging out should clear both the session data and the session cookie. If you only unset one part, the browser or server can still carry stale state. A clean logout route is part of basic PHP application hygiene.

Sessions and cookies become much easier to understand when you think of them as request memory. Cookies remember small values in the browser. Sessions remember more sensitive state on the server.

In real projects, the combination is common: a session keeps the user logged in, while a cookie remembers a display preference or a “remember me” choice. Knowing which part should live where helps you design better authentication and user experience flows.

When you build your own login flow later, return to this distinction first. If the data must stay private or expire with the browser session, lean on sessions. If the data is a user preference that can safely travel with requests, a cookie is often the better fit.