WordPress Cookies: What They Are, Which Ones WordPress Uses, and How to Manage Them

WordPress cookies are small pieces of data stored in a browser. They help a site keep you logged in, remember an interface preference, or save details you chose to enter in a comment form. WordPress uses cookies, but WordPress core is not responsible for every cookie on a site. Plugins, themes, analytics tools, ads, embeds, carts, chat tools, and security services can add their own.

The right way to manage a cookie is to identify who set it, what it does, how long it lasts, where it works, and whether it needs consent. The set of places where it works is its scope. This guide covers those decisions, along with safe ways to set, read, and delete a custom cookie.

TL;DR

WordPress uses cookies for login, logged-in sessions, interface settings, comment convenience, and cookie-support checks. Your plugins and connected services may create many more, so inspect the actual site before changing a cookie, consent setting, or security control.

Does WordPress use cookies?

Yes. WordPress uses cookies to verify a user’s identity and keep built-in features working. Login cookies allow WordPress to recognise a logged-in browser between requests. A settings cookie can remember parts of the user interface. A comment cookie can refill a visitor’s name, email, and website when they choose to save those details.

• Login and authentication: Cookies help WordPress recognise a logged-in user and maintain the session between requests.
• Interface settings: Cookies can remember user-specific dashboard or display preferences.
• Comment forms: A visitor can choose to save their name, email address, and website so the comment form can fill them in next time.
• Browser support checks: WordPress can set a test cookie to confirm that the browser accepts cookies during login and related flows.

Cookies do not contain a complete record of a person. The browser sends a cookie back only when the cookie’s domain, path, and other rules match the request. The site can then use the value to validate a login session, the period a login remains active, or retrieve related information. Clearing a browser cookie does not delete an account, comment, site record, or analytics history.

Core cookies are only the starting point. Analytics, ecommerce, video, chat, and other services may add storage of their own. A first-party cookie comes from the site you are visiting. A third-party cookie comes from another service included on that site. Neither label alone proves that a cookie is essential or exempt from consent.

Which cookies does WordPress core use?

The exact set depends on the WordPress version, site settings, user action, and whether the site uses HTTPS. WordPress documentation describes these core families:

The values of authentication cookies include signed or hashed session data. A hash is a one-way calculation used to check data without storing the original password in the cookie. Do not infer a cookie’s full purpose from its name alone. Check its provider, value format, expiry, domain, path, and security settings.

Current WordPress documentation says login cookies normally last for two days, or 14 days when Remember Me is selected. Comment cookies last about a year by default, and the visitor must choose to save those details. Site code, settings, and version can change these results.

In a clean WordPress 6.9.4 site running PHP 8.4, a login produced the expected cookie families. Authentication, test, and logged-in cookies had Secure, HttpOnly, and SameSite=Lax settings. The settings-time cookie was not HttpOnly, which fits a browser-readable preference. One authentication cookie appeared in two path-scoped entries. That is not a universal WordPress rule, but it shows why scope matters when deleting cookies.

How to find every cookie on a WordPress site

Do not copy a generic cookie list and assume it describes your site. Use the browser’s built-in developer tools, which let you inspect a page, in a private window or clean browser profile. Check stored data and network activity. If cache varies by login state or cookie, Airlift’s WordPress page caching guide explains why those pages need careful exclusions.

• Start with a clean page load: Record cookies that appear before you log in or accept optional settings.
• Test each important feature: Check login, comments, search, cart, checkout, embedded media, chat, analytics, advertising, and language controls.
• Record the useful details: Note the name, provider, purpose, duration, domain, path, first-party or third-party status, and security attributes.
• Watch the network panel: A network request shows when a script or service sends data. Some services use browser storage or send data without creating a cookie.
• Repeat after changes: Recheck the site after adding or updating a plugin, theme, embed, analytics tool, ad service, or checkout system.

This process tells you what the site actually does. It also prevents a common mistake: deleting a cookie without fixing the plugin or script that creates it again.

How to set a custom cookie in WordPress

Use a custom cookie only for a small amount of non-sensitive browser state, such as a display preference. Never store a password, an API key used to connect services, a login secret, or a sensitive user record in a JavaScript-readable cookie.

• Choose a maintainable code location: Prefer a small custom plugin or a maintained snippets workflow. A child theme can work when it is already part of your maintenance process. Avoid editing a parent theme’s functions.php, because a theme update can overwrite the change.

• Set the cookie before page output: PHP, the language WordPress uses on the server, sends cookies in the response headers. A header is an instruction sent before the page content, so the cookie must be set before any output. This example stores a display preference for one hour:

function site_cookie_options( $expires ) {
    return array(
        'expires'  => $expires,
        'path'     => '/',
        'secure'   => is_ssl(),
        'httponly' => true,
        'samesite' => 'Lax',
    );
}

add_action( 'init', function () {
    if ( headers_sent() || isset( $_COOKIE['site_preference'] ) ) {
        return;
    }

    setcookie(
        'site_preference',
        'dark',
        site_cookie_options( time() + HOUR_IN_SECONDS )
    );
} );

• Match the cookie to the feature: Set it only after the user makes the relevant choice. Use the narrowest practical path and domain. A cookie for one tool does not need to be available across every part of the site.

• Keep the value harmless: The HttpOnly setting blocks browser scripts from reading the cookie. If JavaScript, code that runs in the browser, must read it, HttpOnly cannot be used. Keep that cookie non-sensitive and validate its value on the server.

The modern options form of setcookie() supports expiry, path, domain, Secure, HttpOnly, and SameSite settings. If the site runs an older PHP version that does not support this list of settings, use a compatible implementation or update PHP before deploying the example.

⚠️ Note: A cookie is not a database. Store only a short preference or identifier in it. Keep important records on the server, where access and changes can be controlled.

How to read a WordPress cookie safely

On a later request, PHP makes received cookies available through $_COOKIE. Treat this as data sent by the visitor. A visitor can remove, change, or forge a cookie, so never trust its value just because your site created it.

• Check that the value exists: Avoid reading a missing key directly.
• Allow only expected values: If the feature accepts dark or light, reject every other value.
• Escape it when displayed: Escaping converts data into safe text for its output location. Sanitizing input does not replace output escaping.

if ( isset( $_COOKIE['site_preference'] ) ) {
    $preference = sanitize_text_field(
        wp_unslash( $_COOKIE['site_preference'] )
    );

    if ( in_array( $preference, array( 'dark', 'light' ), true ) ) {
        echo esc_html( $preference );
    }
}

JavaScript can read cookies through document.cookie, which returns readable cookies as one text string. It cannot read cookies marked HttpOnly. The MDN cookie reference documents this browser boundary. That boundary is useful: browser code should not handle authentication cookies or other secrets.

How to delete a WordPress cookie

Deleting a cookie means telling the browser to expire it. Removing a value from $_COOKIE changes only the current PHP request. It does not remove the cookie from the browser.

• Expire the browser cookie: Send the same cookie name with an expiry time in the past.
• Reuse the original scope: Match the original path and domain, which control where the cookie works. If those differ, the browser may keep the original cookie and store a separate expired cookie.
• Clear the current request when needed: Unsetting the PHP value can stop the current request from using it, but it is not a replacement for sending the expiry instruction.

if ( ! headers_sent() ) {
    setcookie(
        'site_preference',
        '',
        site_cookie_options( time() - HOUR_IN_SECONDS )
    );
}

JavaScript deletes a readable cookie in the same way by setting its expiry to the past or its Max-Age to zero. In a public-page test, a temporary cookie set with Max-Age=3600, Path=/, and SameSite=Lax appeared immediately. Reissuing it with Max-Age=0 and the same path removed it immediately in that page context. The matching path was part of the result.

⚠️ Note: Clearing cookies in your browser can log you out and remove preferences. It does not erase accounts, comments, logs, or analytics records kept by the site. If a cookie returns, find the plugin or script setting it instead of repeatedly clearing it. If the symptom is stale page content rather than cookie state, BlogVault’s guide to clearing WordPress cache covers the separate cache layers.

Cookie security: what the settings do and do not solve

Use HTTPS, an encrypted connection between the browser and site, across the whole site. Then set security settings based on how the cookie is used:

• Use Secure for HTTPS-only data: The browser sends the cookie only over HTTPS. This reduces exposure on an unencrypted connection.
• Use HttpOnly for server-only data: Browser scripts cannot read the cookie. This can limit damage from cross-site scripting, an attack that injects harmful code into a page.
• Choose SameSite deliberately: SameSite controls when the browser sends a cookie with a request from another site. Lax is a common starting point, but stricter settings can affect legitimate login, payment, or embedded workflows.
• Keep lifetimes proportionate: A short lifetime limits how long a stolen value may work. It does not replace revoking sessions or fixing the cause of a theft.
• Validate and escape values: Check that each value has the expected format, then convert it safely for the place where it appears. Security flags do not make unsafe data safe, and they do not protect a compromised site.

Secure does not prevent JavaScript access. HttpOnly does not stop the browser from sending a cookie with an authorised request. Neither setting fixes cross-site scripting, malware, stolen login details, or unsafe third-party code.

Cookies and consent

Cookie consent depends on the cookie’s purpose, the user’s location, and the rules that apply to the site. Do not assume that every cookie needs the same treatment, and do not assume that every first-party cookie is essential.

A comment form shows a narrower, user-selected convenience cookie, not a general consent manager:

For example, current UK ICO guidance says a site should explain what cookies do and obtain consent before setting cookies that are not strictly necessary for a service the user requested. Advertising, cross-site tracking, which follows activity across different sites, and similar secondary uses generally need consent. Essential authentication, security, or requested-function cookies may fall within an exception, but the purpose must stay limited to what is necessary.

In practice, a consent setup may need to block optional scripts before consent, offer separate choices for categories, record the choice, let visitors change it, and show clear privacy information. A banner that appears while analytics or advertising scripts already run is not enough. Review the rules for every region where the site operates before publishing a consent decision.

• Block optional scripts before consent: Analytics, advertising, and similar scripts should not run before the visitor has given the required consent.
• Give visitors usable control: Explain the categories, record the choice, and let visitors change or withdraw it later.
• Review each region and purpose: A first-party cookie is not automatically essential, and the rules can differ where the site operates.

If your audit finds that you need a banner or category controls, a WordPress cookie consent plugin can help implement them. It does not identify every cookie automatically, guarantee legal compliance, or replace a site-specific review.

When cookies point to a security problem

Cookie settings are only one part of site security. Malware, cross-site scripting, unsafe third-party code, stolen login details, and login-cookie theft can all put an account at risk. HttpOnly may stop one script from reading one cookie, but it cannot repair a hacked site or prevent every authorised request.

If an administrator is logged out unexpectedly, a login appears in an unfamiliar location, or an authentication cookie may have been stolen, treat it as a security incident. End active logins, change affected passwords, inspect recent account and code changes, and scan the site for compromise. Clearing one browser’s cookies is not enough.

• End active logins and change affected passwords: Revoke sessions and reset credentials that may have been exposed.
• Inspect the site for a cause: Review recent account and code changes, then scan for malware or other compromise.
• Treat browser clearing as insufficient: Removing one cookie can log out one browser, but it does not investigate or contain a hacked site.

MalCare can help investigate broader WordPress security problems, including possible cookie or session theft. It is not a cookie inventory tool, consent banner, or legal service.

Which next step applies to you?

For a site owner, start with the page or feature that triggered an unfamiliar cookie, then inspect its provider and scope:

• If you are a visitor resetting a login: Clear the site’s cookies, then sign in again. Expect saved preferences to disappear.
• If you own the site and found an unfamiliar cookie: Identify its provider, purpose, scope, and trigger before deleting it. Check the plugin, script, embed, or feature that created it.
• If you are adding a feature: Use a maintainable code location, set deliberate security settings, validate the value, and use the same scope when deleting it.
• If the cookie measures or tracks activity: Review consent requirements for the relevant regions or countries before enabling it.
• If you suspect stolen access: Revoke sessions and investigate the site as a security incident.

Conclusion

WordPress cookies are not one fixed list. Core cookies support login, sessions, settings, comments, and browser checks, while the site’s plugins and connected services decide what else appears. Identify each cookie by its purpose, provider, scope, lifetime, and security attributes before changing it.

For custom cookies, store only non-sensitive state, set them before output, validate every value, and match the original scope when deleting them. Keep consent decisions separate from security work, and treat a possible stolen authentication cookie as a security incident that needs investigation.