Cookies & Browser Storage

The Pendo Web SDK persists a small amount of state in the browser — visitor and account identity, session bookkeeping, and short-lived guide-display state. Where that state is stored (cookies, localStorage, or sessionStorage) and therefore how much of it is sent on every request as a Cookie header depends on how you configure the SDK.

This page summarizes the total cookie footprint you can expect under common configurations. For the full key-by-key reference of every stored value, see localStorage values and sessionStorage values.

Where the SDK stores state

Mechanism	When it's used	Sent on requests?
localStorage	Default. When no cookieDomain is set, identity and most state is kept in localStorage.	No
Cookies	When a cookieDomain is configured, so identity can be shared across subdomains.	Yes — adds to the Cookie request header on the matching domain.
sessionStorage	Per-tab/session bookkeeping (tab id, session id, clone detection).	No
In-memory only	When disableCookies is set, nothing is persisted across page loads.	No

The key takeaway: without a cookieDomain, the SDK's cookie footprint is effectively zero — identity lives in localStorage. Cookies are only used when you need identity to be shared across subdomains, which is what cookieDomain (and cross-domain identity) enable.

note

Storage keys are named _pendo_<key>.<suffix>, where <suffix> is your application id by default. Values are URL-encoded when written, so the byte counts below reflect the encoded size that actually travels in the Cookie header.

Estimated cookie footprint

The figures below were measured against a Web SDK build with all independent plugins loaded (session replay, console/network/text capture, feedback, etc.), using a representative ~40-character visitor id and account id. Treat them as estimates: the footprint scales with the length of your visitor/ account ids, your identityStorageSuffix, and any UTM parameters present in the page URL.

Configuration	Cookies	Approx. Cookie header size
Default (no cookieDomain)	0	~0 B (state is in localStorage)
cookieDomain set	5	~470 B
Cross-domain identity (cookieDomain + identityStorageSuffix)	5	~400 B
Worst case (above + UTM params + guide-display state)	9	~1.5 KB

These sit comfortably within browser limits (typically ~4 KB per cookie and ~180 cookies per domain), but they add to every request on the cookie domain, so they're worth understanding when you share a domain with other cookie-heavy applications.

note

The guide-display cookies always use the application-id suffix (not the identityStorageSuffix), so their names remain the longer GUID form even when cross-domain identity is enabled. They also expire 10 seconds after the interaction, so this peak is transient.

Cookie consent

To respect the consent a visitor gives in your cookie banner or consent management platform, the Web SDK supports Cookie Consent Levels. Pass the visitor's consent tiers on initialize or update them later, and the SDK collects only the data — identity, analytics, guides, and session replay — that those tiers allow.

Reducing the footprint

• Leave cookieDomain unset unless you need cross-subdomain identity — the default localStorage path sends nothing on requests.
• Use identityStorageSuffix when running multiple Pendo applications on one domain, so identity cookies are shared rather than duplicated per application.
• Set disableCookies to keep all state in memory (not persisted across page loads) where persistence isn't needed.
• Keep visitor and account ids reasonably short — id length is the main driver of identity-cookie size.