Cookie
A cookie in the Salesforce context is a small key-value file stored in a user browser by the platform, an Experience Cloud site, a Salesforce Sites page, or a marketing product like Marketing Cloud Account Engagement.
Definition
A cookie in the Salesforce context is a small key-value file stored in a user browser by the platform, an Experience Cloud site, a Salesforce Sites page, or a marketing product like Marketing Cloud Account Engagement. Cookies let Salesforce keep a user signed in across separate HTTP requests, recognize returning visitors on public pages, remember preferences, and tie engagement back to a known prospect for marketing analytics.
Cookie handling in Salesforce falls into two groups. Essential cookies (session, authentication, CSRF protection, and instance routing) are required for the product to function, so they ship enabled. Non-essential cookies (marketing tracking, statistics, and personalization) fall under privacy laws like GDPR and CCPA, and they need user consent before they are set. Salesforce ships a Cookie Consent solution for Experience Cloud to capture that consent.
How cookies work across the Salesforce platform
Session and authentication cookies
The cookie that matters most is the session cookie, written as sid. Salesforce sets it when a user authenticates, and the browser sends it back on every later request so the server knows who is calling. In modern releases the session cookie is flagged HttpOnly, which stops page JavaScript from reading it, and Secure, which keeps it on HTTPS only. The Salesforce Security Guide also offers a session setting to require the HttpOnly attribute, and you should keep it on. Other cookies in this group cover OAuth authorization state and CSRF tokens that block forged form posts. None of these are optional. The platform cannot maintain a logged-in session without them, so they are always treated as required cookies and sit outside any consent banner. When users complain about being logged out at random, the session cookie is usually the thing a browser privacy setting is dropping. Knowing the sid is the session anchor helps you separate a real Salesforce problem from a browser configuration problem during triage, before you open a support case that turns out to be a Safari or incognito setting.
BrowserId and instance routing cookies
Salesforce sets a BrowserId cookie that holds a long-lived identifier for the browser. It survives logout and helps with analytics, abuse detection, and steering a returning browser back to a consistent experience. For years a companion secure cookie named BrowserId_sec rode alongside it. Salesforce removed BrowserId_sec in a 2025 release, which is a good example of why you should never hardcode a list of Salesforce cookie names into integration logic. The set changes between releases, and code that assumes a fixed list breaks quietly. A separate concern is instance routing. Salesforce runs many server instances, and certain cookies plus the My Domain hostname help direct your web and API traffic to the correct one. This is why My Domain matters so much for cookie reliability. When your org is served from a first-party hostname like yourcompany.my.salesforce.com, the session and routing cookies are first-party cookies, and browsers treat first-party cookies far more leniently than third-party ones. Read the security release notes each cycle, because cookie names and flags get adjusted regularly.
Experience Cloud and Salesforce Sites cookies
Public-facing Salesforce surfaces add their own cookies on top of the platform set. Experience Cloud sites place session cookies on the site hostname, and Salesforce publishes an Experience Cloud Cookies reference that lists what gets set and why. Authenticated sites lean on OAuth or SAML during login and then settle into normal session behavior. The big lever here is My Domain again, because an Experience Cloud site served from your own domain keeps its cookies first-party. Salesforce Sites, the older public page product, exposes cookies directly to developers through Apex. You can read and write your own cookies from controller code, which is handy for things like remembering a visitor choice on an anonymous page. Keep custom cookies lean and never store anything sensitive in them, since anything you set on a public page is reachable by the browser. Treat custom cookies as preference or statistics cookies for consent purposes, which means they should respect whatever choice the visitor made in your cookie banner rather than being written unconditionally on page load.
Setting cookies from Apex on Salesforce Sites
Salesforce gives developers a first-class Apex Cookie class for Salesforce Sites and Visualforce, found in the Apex Reference Guide. You build a cookie object with a constructor that takes a name, value, path, max age in seconds, and a Secure flag. A newer constructor adds a SameSite argument so you can declare None, Lax, or Strict directly from code. Once you have one or more Cookie objects, you attach them to a PageReference using its setCookies method, and they go out with the response. Reading is just as direct: ApexPages.currentPage().getCookies() returns what the browser sent. A worked example: an anonymous quoting page wants to remember a returning visitor without forcing a login. The controller checks for a custom cookie, and if none exists it builds one with a max age of a few weeks and a SameSite value of Lax, then sets it through the PageReference. On the next visit the controller reads the cookie and prefills the form. Wrap that write behind a consent check so the cookie is only set after the visitor accepts preference or statistics cookies in your banner.
Marketing tracking cookies and opt-in
Marketing Cloud Account Engagement, still widely called Pardot, tracks anonymous visitors and known prospects with cookies. The pi_opt_in cookie is the control point. Account Engagement only records a page view when the opt-in value allows it, and the documented tracking and consent functions can clear existing visitor cookies and set pi_opt_in to false when a visitor declines. Account Engagement supports first-party tracking, where the cookies are served from your own tracker domain rather than a shared third-party one, which holds up far better against browser cookie blocking. You can also configure how long these cookies last. All of this is non-essential by definition, so it must wait for consent in regions with cookie laws. The practical takeaway is that marketing cookies and the platform session cookie are governed differently. The session cookie keeps a logged-in user signed in and is required. The Account Engagement cookies feed analytics and personalization and are optional. Mixing the two up in a consent design is a common mistake that either breaks login or quietly violates a regulation, so map every cookie to a category before you ship.
Cookie Consent on Experience Cloud
Salesforce ships a Cookie Consent capability for Experience Cloud that puts the consent workflow into a Lightning Web Component you control. Two cookies make it work: CookieConsentPolicy records whether consent is in force, and CookieConsent records the visitor decisions. Your component imports the lightning/userConsentCookie module, which exposes isCategoryAllowedForCurrentConsent so other code can check a category, and setCookieConsent so your banner can persist the visitor choices. The model uses four categories: Required, Marketing, Preference, and Statistics. Required cookies always run because the site cannot function without them. The other three are gated by the visitor decision. You design the banner UI yourself, wiring a toggle for each category to those module functions, which keeps the look on-brand while Salesforce handles the underlying cookies. Because the decision lives in a standard place, your own components and third-party scripts can ask whether a category is allowed before they fire. This is the hook that lets you load a marketing pixel only after the visitor accepts marketing cookies, instead of dropping it on every page load and hoping nobody complains.
Expiration, SameSite, and troubleshooting
Cookies differ a lot in lifetime. The session cookie is short-lived and tied to the session, so it expires when the session ends or times out. BrowserId and marketing cookies live much longer, often measured in months, and for Account Engagement the duration is configurable. The SameSite attribute decides whether a cookie travels on cross-site requests. Lax is the common modern default and blocks most cross-site forgery while still allowing top-level navigation links to carry the cookie. Strict is tighter and can break legitimate cross-domain flows, while None requires the Secure flag and is meant for genuine cross-site cases. When you troubleshoot, open the browser developer tools Application tab and inspect each cookie name along with its Secure, HttpOnly, and SameSite flags. Salesforce adjusts these defaults across releases, so a cross-domain integration that worked last quarter can break after an upgrade purely because a flag tightened. The earlier BrowserId_sec removal is a real example of that churn. Compare what the browser actually received against what your integration expects, and check the security release notes for the cycle before you assume the bug is in your own code.
How to set up Cookie Consent on Experience Cloud
Configure the Cookie Consent capability on an Experience Cloud site so non-essential cookies only run after a visitor agrees. This covers the high-level admin and developer steps; build the banner UI to match your brand.
- Turn on consent in Security and Privacy settings
In Setup, open the Security and Privacy area and enable cookie consent management for the org. Decide whether consent applies only to Required cookies or extends to Marketing, Preference, and Statistics categories.
- Build a Cookie Consent Lightning Web Component
Create an LWC that imports the lightning/userConsentCookie module. Add a toggle for each category and wire the controls to setCookieConsent so the visitor decision is stored in the CookieConsent cookie.
- Place the component on the site
In Experience Builder, add your consent component to the site so it appears on first visit. Confirm the CookieConsentPolicy and CookieConsent cookies are written after a choice is made.
- Gate non-essential cookies behind the decision
Before any marketing or statistics script runs, call isCategoryAllowedForCurrentConsent for its category. Only load the pixel or set the cookie when that category is allowed.
Whether consent covers only Required cookies or the full set of Marketing, Preference, and Statistics categories.
The four buckets (Required, Marketing, Preference, Statistics) that each cookie on the site maps to for consent decisions.
Whether you wire the banner to a third-party Consent Management Platform or keep the workflow fully inside Salesforce.
- Required cookies always run; do not try to gate the session cookie behind consent or you will break login.
- The banner UI is yours to build. Salesforce supplies the module and storage cookies, not a finished design.
- Map every cookie on the site to a category before launch, including custom cookies you set from Apex or LWC.
Prefer this walkthrough as its own page? How to Cookie in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- User Consent Cookie Module (lightning/userConsentCookie)Salesforce
- Experience Cloud CookiesSalesforce
Straight from the source - Salesforce's reference material on Cookie.
Hands-on resources to go deeper on Cookie.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Cookie in the context of a Salesforce-hosted site?
Q2. Why are third-party Cookies becoming more restricted across modern browsers?
Q3. What is a good practice for handling sensitive Cookies on a Salesforce site?
Discussion
Loading discussion…