What Are Session Cookies in WordPress?
A session cookie is a small text file stored in the browser that expires as soon as the user closes the tab or ends the browsing session. WordPress relies on session cookies to keep logged-in users authenticated, remember admin dashboard settings, and test whether the browser accepts cookies at all.
WordPress core does not use PHP sessions (PHPSESSID). Instead, it handles session management through its own cookie-based system, storing authentication tokens and user preferences directly in named cookies. This distinction matters for performance and security: native PHP sessions write to the filesystem, break page caching, and introduce vulnerabilities like session fixation and hijacking. WordPress avoids all of that by design.
The cookies WordPress generates on its own are relatively few. Trouble starts when plugins, themes, and e-commerce extensions pile on their own session cookies - each with different lifespans, scopes, and legal implications.
Default WordPress Session Cookies
A clean WordPress installation - no plugins, no custom theme logic - sets only a handful of cookies. Each one serves a specific technical function.
| Cookie Name | Purpose | Lifespan | Consent Required? |
|---|---|---|---|
wordpress_[hash] | Stores authentication details (username + hashed password) for the admin area (/wp-admin/) | Session or up to 14 days if "Remember Me" is ticked | No - strictly necessary |
wordpress_logged_in_[hash] | Identifies logged-in users on both the front end and back end | Session or up to 14 days | No - strictly necessary |
wp-settings-[UID] | Stores personal dashboard and admin interface preferences (e.g. editor layout, screen options) | 1 year | No - strictly necessary for admin users |
wp-settings-time-[UID] | Records the time wp-settings was last set | 1 year | No - strictly necessary for admin users |
wordpress_test_cookie | Tests whether the browser supports cookies | Session | No - strictly necessary |
wp_lang | Stores the selected language on the login screen | Session | No - strictly necessary |
The [hash] in the cookie name is derived from your site URL, making each cookie unique to your domain. The [UID] is the numeric user ID from the wp_users table.
Notice that wp-settings-[UID] and its timestamp companion have a one-year lifespan. Technically these are persistent cookies, not session cookies. They persist across browser restarts. But because they only activate for authenticated admin users and store interface preferences - not tracking data - they still fall under the strictly necessary exemption.
Comment Cookies: The One Default That Needs Attention
When a visitor leaves a comment on a post, WordPress can store three cookies on their device: comment_author_[hash], comment_author_email_[hash], and comment_author_url_[hash]. These persist for 347 days and remember the commenter's name, email, and website URL so they do not need to re-enter this information next time.
These are not strictly necessary. A visitor can still comment without them. Under GDPR and the ePrivacy Directive, you need consent before setting them.
WordPress addressed this in version 4.9.6 by adding a consent checkbox under Settings > Discussion. When enabled, a "Save my name, email, and website in this browser for the next time I comment" checkbox appears on the comment form. The cookies are only set if the visitor ticks that box. If your site has comments enabled, verify this checkbox is active.
WooCommerce Session Cookies
If your WordPress site runs WooCommerce, an additional set of session cookies comes into play. WooCommerce does not use PHP sessions either - it maintains its own session handler backed by a database table (wp_woocommerce_sessions) and a browser cookie.
| Cookie Name | Purpose | Lifespan | Consent Required? |
|---|---|---|---|
woocommerce_cart_hash | Tracks cart contents to display accurate totals and detect changes | Session | No - strictly necessary for cart functionality |
woocommerce_items_in_cart | Flags whether items exist in the cart (used for header cart icons) | Session | No - strictly necessary |
wp_woocommerce_session_[hash] | Contains a unique ID linking the browser to a server-side session record | 2 days | No - strictly necessary for cart/checkout |
woocommerce_recently_viewed | Stores product IDs the visitor has viewed | Session | Arguable - see below |
The cart and session cookies are textbook examples of the Article 5(3) exemption. A visitor explicitly requests the shopping service by adding an item to the cart, and the cookie is strictly necessary to provide that service. Block these before consent and the add-to-cart button breaks, the checkout flow collapses, and conversions drop to zero.
The woocommerce_recently_viewed cookie sits in a grey area. It powers "recently viewed products" widgets, which enhance browsing but are not essential for completing a purchase. Some DPAs would consider this a functional cookie requiring consent; others might accept it under the strictly necessary exemption if the widget is a core part of the requested service. The safest approach: categorise it as a preference cookie and obtain consent before setting it.
Plugin and Theme Cookies You Need to Audit
WordPress core is relatively clean. The real cookie sprawl comes from third-party plugins. Every contact form, caching layer, analytics tool, and social sharing widget can introduce its own session cookies - many of which do require consent.
Common offenders include Google Analytics (_ga, _gid), which always requires consent under GDPR; Meta Pixel (_fbp), a marketing cookie with a 90-day lifespan; multilingual plugins like WPML and Polylang that store language preferences in cookies like pll_language; and form plugins that set cookies to prevent duplicate submissions.
The only way to know exactly which cookies your site sets is to run a cookie scan. Deactivating all plugins and re-activating them one by one is the manual method described in the WordPress developer documentation - but automated scanning is faster and catches cookies that only appear under specific user flows.
The Legal Framework: When Session Cookies Need Consent
Article 5(3) of the ePrivacy Directive is the rule that governs cookie consent across the EU. It states that storing information on a user's device requires prior consent, with two exceptions: cookies used solely to carry out a communication over a network, and cookies that are strictly necessary to provide a service the user has explicitly requested.
WordPress login cookies fall squarely in the second exception. The user requests access to a password-protected area; the cookie is strictly necessary to provide that access. No consent needed.
The French CNIL publishes a specific list of cookie types that qualify for the exemption, which includes authentication cookies, shopping cart cookies, consent-state cookies, and load-balancing cookies. Between December 2022 and December 2024, the CNIL issued combined fines exceeding 139 million euros for breaches of cookie consent rules under Article 82 of the French Data Protection Act. In September 2025, the authority imposed record fines of 325 million euros against Google and 150 million euros against Shein for setting non-essential cookies before obtaining consent.
In the UK, PECR (the Privacy and Electronic Communications Regulations) mirrors the ePrivacy Directive. The ICO has been expanding its enforcement programme, sending compliance letters to the top 1,000 UK websites. The UK Data (Use and Access) Act 2025 will raise the maximum PECR fine from 500,000 pounds to 17.5 million pounds or 4% of global turnover - aligning penalties with GDPR-level sanctions.
Under the CCPA, session cookies that do not track behaviour or sell personal information are generally unaffected. But if a plugin sets a cookie enabling cross-site tracking or third-party data sharing, the California opt-out requirements apply.
Caching, Performance, and Session Cookies
Session cookies interact with page caching in ways that can break your site. When a caching plugin or CDN serves a static copy of a page, PHP does not execute, and cookies are not read. For logged-in users or WooCommerce shoppers with items in their cart, this means stale data - an empty cart, the wrong user name, or missing admin bars.
Most managed WordPress hosts detect the wordpress_logged_in_[hash] and wp_woocommerce_session_ cookies and bypass the cache when they are present. If you use a CDN like Cloudflare, configure cache bypass rules manually for these cookie names.
Some plugins use native PHP sessions (PHPSESSID) instead of WordPress-native cookies. This is discouraged in the WordPress plugin development guidelines. PHP sessions generate unique file-system entries per visitor, bust page caching entirely, and create security risks. If a cookie scan reveals PHPSESSID on your site, identify the responsible plugin and switch to one that uses the WordPress database for session storage.
How to Audit and Manage WordPress Session Cookies
A structured audit involves four steps.
Step one: scan. Use a cookie scanning tool to detect every cookie your site sets, including those that appear only after login, after adding a product to the cart, or after submitting a form. A scan from the front end alone will miss admin-only cookies.
Step two: classify. Sort each cookie into the correct category - strictly necessary, functional, analytics, or marketing. WordPress core cookies are strictly necessary. Comment cookies and woocommerce_recently_viewed are functional. _ga, _gid, and _fbp are analytics or marketing.
Step three: block non-essential cookies before consent. Configure your consent management platform to prevent analytics and marketing scripts from loading until the visitor opts in. Strictly necessary cookies like wordpress_logged_in_[hash] and woocommerce_cart_hash must load immediately and should never be blocked.
Step four: document. List every cookie in your cookie policy with its name, provider, purpose, category, and expiry. The ePrivacy Directive and GDPR both require transparent information about cookie use, even for cookies exempt from consent.
Frequently Asked Questions
Does WordPress set cookies for visitors who are not logged in?
A clean WordPress installation sets wordpress_test_cookie on the login page, but anonymous front-end visitors receive no cookies from WordPress core. Comment cookies are only set if a visitor submits a comment and ticks the consent checkbox. Plugin-generated cookies are a different matter and depend entirely on what you have installed.
Are WordPress login cookies exempt from GDPR consent?
Yes. Login and authentication cookies (wordpress_[hash], wordpress_logged_in_[hash]) are strictly necessary to provide the service the user has requested - accessing a protected area of the site. Article 5(3) of the ePrivacy Directive exempts them from the consent requirement. You still need to disclose them in your cookie policy.
Why does my WordPress site set a PHPSESSID cookie?
WordPress core does not use PHP sessions. If you see a PHPSESSID cookie, a plugin or theme is calling session_start(). This is considered bad practice because it breaks page caching and introduces security vulnerabilities. Identify the responsible plugin through a process of elimination and look for an alternative that uses the WordPress database for session storage.
Do WooCommerce cart cookies need consent under GDPR?
No. Cart cookies like woocommerce_cart_hash and wp_woocommerce_session_[hash] are strictly necessary to provide the shopping service the user has requested by adding items to their cart. Blocking them before consent would break the checkout flow entirely.
How long do WordPress session cookies last?
True session cookies (wordpress_test_cookie, wp_lang, woocommerce_cart_hash) expire when the browser closes. Authentication cookies last up to 14 days if the user selects "Remember Me" - which technically makes them persistent, not session, cookies. The wp-settings cookies persist for one year.
Can I change the expiry time of WordPress authentication cookies?
Yes. WordPress provides the auth_cookie_expiration filter hook, which accepts the default expiry in seconds and returns a new value. Shortening the expiry improves security; lengthening it improves convenience. The default is 48 hours for a standard login and 14 days for a "Remember Me" login.
Should comment cookies be listed in my cookie policy?
Yes. Even though WordPress only sets them after the visitor ticks the consent checkbox, you must still disclose their existence, purpose, and duration in your cookie policy. Transparency is required regardless of whether the cookie is consent-exempt or consent-gated.
Keep Your WordPress Cookie Inventory Under Control
WordPress core keeps its cookie footprint small, but every plugin you install can add to it. A regular scan identifies new cookies before they become a compliance risk. Kukie.io detects, categorises, and documents every cookie on your WordPress site - including those that only appear after login or during checkout.
