Managing persistence and cookies

Last updated:

|Edit this page

For PostHog to work optimally, we store small amount of information about the user on the user's browser. This ensures we identify users properly if they navigates away from your site and come back later. We store the following information in the user's browser:

  • User's ID
  • Session ID & Device ID
  • Active & enabled feature flags
  • Any super properties you have defined.
  • Some PostHog configuration options (e.g. whether session recording is enabled)

By default, we store all this information in both a cookie and localStorage, which means PostHog can identify your users across subdomains. By default, the name of the cookie PostHog sets is ph_<project_api_key>_posthog and it expires after 365 days.

If you want to change how PostHog stores this information, you can do so with the persistence configuration option:

  • persistence: "localStorage+cookie" (default): Limited things are stored in the cookie such as the distinctID and the sessionID, and everything else in the browser's localStorage.

  • persistence: "cookie" : Stores all data in a cookie.

  • persistence: "localStorage": Stores everything in localStorage.

  • persistence: "sessionStorage": Stores everything in sessionStorage.

  • persistence: "memory": Stores everything in page memory, which means data is only persisted for the duration of the page view.

To change persistence values without reinitializing PostHog, you can use the posthog.set_config() method. This enables you to switch from memory to cookies to better comply with privacy regulations.

Web
const handleCookieConsent = (consent) => {
posthog.set_config({ persistence: consent === 'yes' ? 'localStorage+cookie' : 'memory' });
localStorage.setItem('cookie_consent', consent);
};

Persistence caveats

  • Be aware that localStorage and sessionStorage can't be used across subdomains. If you have multiple sites on the same domain, you may want to consider a cookie option or make sure to set all super properties across each subdomain.

  • Due to the size limitation of cookies you may run into 431 Request Header Fields Too Large errors (e.g. if you have a lot of feature flags). In that case, use localStorage+cookie.

  • If you don't want PostHog to store anything on the user's browser (e.g. if you want to rely on your own identification mechanism only or want completely anonymous users), you can set disable_persistence: true in PostHog's config. If you do this, remember to call posthog.identify every time your app loads. If you don't, every page refresh is treated as a new and different user.

Questions? Ask Max AI.

It's easier than reading through 598 docs articles.

Community questions

Was this page useful?

Next article

Android

It uses an internal queue to make calls fast and non-blocking. It also batches requests and flushes asynchronously, making it perfect to use in any part of your mobile app. Installation Capturing events Identifying users We highly recommend reading our section on Identifying users to better understand how to correctly use this method. Get the current user's distinct ID You may find it helpful to get the current user's distinct ID. For example, to check whether you've already called identify…

Read next article