WordPress's own session cookies are wordpress_[hash], wordpress_logged_in_[hash] and wordpress_test_cookie, plus wp-settings-[UID] for signed-in users' admin preferences. All of them are strictly necessary, so none needs consent. The cookies that do need it come from comments, plugins, themes and e-commerce extensions, which is where most WordPress sites need a consent banner.
What session cookies are in WordPress
A session cookie expires when the visitor closes the browser, while a persistent cookie survives for a set time. WordPress uses both to keep signed-in users authenticated, remember admin dashboard settings and test whether the browser accepts cookies at all.
WordPress core does not use PHP sessions (PHPSESSID). It handles sessions through its own named cookies instead, storing authentication tokens and preferences directly. That matters for performance and security: native PHP sessions write to the file system, break page caching and open the door to session fixation and hijacking. WordPress avoids that by design.
The cookies WordPress sets on its own are few. The trouble starts when plugins, themes and e-commerce extensions add their own, each with a different lifespan, scope and legal position.
Default WordPress session cookies
A clean WordPress installation, with no plugins and no custom theme logic, sets only a handful of cookies, listed in WordPress's own cookie documentation. Each serves a specific technical function. You can look any of them up in the cookie database.
| Cookie name | Purpose | Lifespan | Consent needed? |
|---|---|---|---|
wordpress_[hash] | Stores authentication details for the admin area (/wp-admin/) | Session, or up to 14 days with "Remember Me" | No, strictly necessary |
wordpress_logged_in_[hash] | Identifies signed-in users on the front end and the admin | Session, or up to 14 days | No, strictly necessary |
wp-settings-[UID] | Stores a user's admin interface preferences, such as screen options | 1 year | No, strictly necessary for admin users |
wp-settings-time-[UID] | Records when wp-settings was last set | 1 year | No, strictly necessary for admin users |
wordpress_test_cookie | Tests whether the browser accepts cookies | Session | No, strictly necessary |
wp_lang | Stores the language chosen on the login screen | Session | No, strictly necessary |
The [hash] in a 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, which is why searches such as "wp-settings-time-1" show the administrator's cookie. WordPress's documentation writes the pair as wp-settings-{time}-[UID].
The wp-settings cookies last a year, so strictly speaking they are persistent, not session, cookies. Because they only appear for signed-in users and store interface preferences rather than tracking data, they still fall under the strictly necessary exemption.
If a WordPress page shows "Cookies are blocked or not supported by your browser", wordpress_test_cookie could not be written. WordPress's documentation suggests deleting your cookies after a site move and clearing the server cache if you use a caching plugin.
Comment cookies: the one default that needs attention
When a visitor leaves a comment, WordPress can store three cookies on their device: comment_author_[hash], comment_author_email_[hash] and comment_author_url_[hash]. They last just under a year and remember the commenter's name, email and website so they need not type them again.
These are not strictly necessary: a visitor can comment without them. Under the GDPR and the ePrivacy Directive, you need consent before setting them.
WordPress addressed this in version 4.9.6 with a consent checkbox, controlled under Settings > Discussion. When it is on, the comment form shows "Save my name, email, and website in this browser for the next time I comment", and the cookies are set only if the visitor ticks it. If your site has comments enabled, check that the checkbox is active.
WooCommerce session cookies
If your site runs WooCommerce, another set of session cookies comes into play. WooCommerce does not use PHP sessions either: it keeps its own session handler backed by a database table (wp_woocommerce_sessions) and a browser cookie.
| Cookie name | Purpose | Lifespan | Consent needed? |
|---|---|---|---|
woocommerce_cart_hash | Tracks cart contents to show accurate totals and detect changes | Session | No, strictly necessary for the cart |
woocommerce_items_in_cart | Flags whether the cart has items, for header cart icons | Session | No, strictly necessary |
wp_woocommerce_session_[hash] | Links the browser to a server-side session record | 2 days | No, strictly necessary for cart and checkout |
woocommerce_recently_viewed | Stores the product IDs the visitor has viewed | Session | Arguable, see below |
sbjs_session, sbjs_first and related | Order attribution: where a visit came from | 30 minutes or session | Yes |
The cart and session cookies are textbook examples of the Article 5(3) exemption. A visitor asks for the shopping service by adding an item to the cart, and the cookie is strictly necessary to provide it. Block them before consent and the add-to-cart button and checkout stop working.
The woocommerce_recently_viewed cookie sits in a grey area. It powers "recently viewed products" widgets, which help browsing but are not needed to complete a purchase. Some regulators would treat it as a functional cookie that needs consent, others might accept it as strictly necessary if the widget is a core part of the service. The cautious approach is to treat it as a preference cookie and ask first.
The sbjs_* cookies come from WooCommerce's order attribution feature, which records traffic sources for orders. WooCommerce says the feature works with the WP Consent API, so a consent tool connected to that API can hold it back until the visitor agrees.
Plugin and theme cookies you need to audit
WordPress core is relatively clean. Most cookies come from third-party plugins: every contact form, caching layer, analytics tool and social sharing widget can add its own, and many need consent.
Google Analytics (_ga, _ga_<container-id>) needs consent under the GDPR, and the Meta Pixel sets _fbp, a marketing cookie that lasts 90 days. Multilingual plugins such as Polylang store the language in pll_language, and some form plugins set cookies to prevent duplicate submissions.
The only way to know exactly which cookies your site sets is to scan it. Deactivating all plugins and reactivating them one by one is the manual method, but an automated scan is faster and catches cookies that only appear on certain pages or after certain actions.
The legal framework: when session cookies need consent
Article 5(3) of the ePrivacy Directive is the rule behind cookie consent across the EU. Storing information on a visitor's device needs prior consent, with two exceptions: cookies used only to carry out a communication over a network, and cookies strictly necessary to provide a service the visitor explicitly asked for.
WordPress login cookies fall in the second exception. The user asks for access to a protected area, and the cookie is strictly necessary to provide it, so no consent is needed.
The French CNIL lists the kinds of cookie that qualify for the exemption, including authentication, shopping cart, consent-state and load-balancing cookies. In 2025 it issued 83 sanctions totalling 486,839,500 euros across all its areas, according to its annual summary, and 21 of the organisations sanctioned had breached the rules on trackers. They included SHEIN, fined 150 million euros on 1 September 2025 for placing advertising cookies before visitors made any choice. On the same day the CNIL fined Google 325 million euros over ads shown between Gmail emails and invalid consent to advertising cookies at account creation.
In the UK, the Privacy and Electronic Communications Regulations (PECR) mirror the ePrivacy Directive. The ICO wrote to the operators of the top 1,000 UK websites, and in December 2025 reported that 979 of them met its checks. Since 5 February 2026, the UK Data (Use and Access) Act 2025 has let the ICO fine up to 17.5 million pounds or 4% of global turnover under PECR, according to the ICO's commencement statement. The same Act added PECR exceptions for some analytics and appearance cookies.
Under the CCPA, session cookies that do not track behaviour or sell personal information are generally unaffected. If a plugin sets a cookie that enables cross-site tracking or sharing data with third parties for advertising, the California opt-out rules 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 run and cookies are not read. For signed-in users or WooCommerce shoppers with items in the cart, that means stale data: an empty cart, the wrong user name or a missing admin bar.
Most managed WordPress hosts detect the wordpress_logged_in_[hash] and wp_woocommerce_session_ cookies and bypass the cache when they are present. On a CDN such as Cloudflare, set cache bypass rules for these cookie names yourself.
Some plugins use native PHP sessions (PHPSESSID) instead of WordPress's own cookies. PHP sessions create a file-system entry per visitor, defeat page caching and add security risks. If a scan shows PHPSESSID on your site, find the plugin responsible and look for one that keeps sessions in the WordPress database.
How to audit and manage WordPress session cookies
A structured audit has four steps.
Step one: scan. Use a cookie scanner to find every cookie your public pages set, including those that appear after adding a product to the cart or loading certain pages. Check the cookies that appear only after signing in to the admin by hand in the browser, since a scan of the public site does not sign in.
Step two: classify. Sort each cookie into a category: strictly necessary, functional, analytics or marketing. WordPress core cookies are strictly necessary. Comment cookies and woocommerce_recently_viewed are functional. _ga, sbjs_* and _fbp are analytics or marketing.
Step three: block non-essential cookies before consent. Set your consent tool to stop analytics and marketing scripts until the visitor opts in. Strictly necessary cookies such as 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 the GDPR both require clear information about cookies, even those exempt from consent. Kukie.io for WordPress shows how its plugin adds a banner to every page.
Questions about WordPress session cookies
Does WordPress set cookies for visitors who are not signed in?
A clean WordPress install sets wordpress_test_cookie on the login page, but anonymous visitors to the public site get no cookies from WordPress core. Comment cookies are set only if a visitor comments and ticks the consent checkbox. Plugin cookies depend on what you have installed.
Are WordPress login cookies exempt from consent?
Yes. Login and authentication cookies, wordpress_[hash] and wordpress_logged_in_[hash], are strictly necessary to give the user the access they asked for, so Article 5(3) of the ePrivacy Directive exempts them. 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, so a PHPSESSID cookie means a plugin or theme calls session_start(). That breaks page caching and adds security risk. Find the plugin by elimination and look for an alternative that stores sessions in the WordPress database.
Do WooCommerce cart cookies need consent?
No. Cart cookies such as woocommerce_cart_hash and wp_woocommerce_session_[hash] are strictly necessary for the shopping service the visitor asked for by adding items. The sbjs_* order attribution cookies are different and need consent.
How long do WordPress session cookies last?
True session cookies, such as wordpress_test_cookie, wp_lang and woocommerce_cart_hash, expire when the browser closes. Authentication cookies last up to 14 days with Remember Me, which makes them persistent. The wp-settings cookies last one year.
Can I change the expiry time of WordPress authentication cookies?
Yes. The auth_cookie_expiration filter takes the default expiry in seconds and returns a new value. The default is 48 hours for a normal login and 14 days with Remember Me. Shorter is more secure, longer is more convenient.
Should comment cookies be listed in my cookie policy?
Yes. Even though WordPress sets them only after the visitor ticks the checkbox, your cookie policy must still state what they are, what they do and how long they last.
See which cookies your WordPress plugins add
WordPress core keeps its cookie list short, but each plugin can add to it. The Cookie scanner loads your public pages like a visitor and lists every cookie it finds by name and category, so new ones show up before they cause problems.
