🥳 You have completed all topics in the Handbook. Click here to claim your certificate!

3. Cookies and other browser storage

Storage mechanisms are an absolutely vital part of how the web works. Without browser storage, you would need to log in again and again with every page load, and you would never be able to store items in your shopping cart beyond the initial page.

The web is essentially stateless.

This means that what happens during any given page load is not “remembered” once the browser user navigates away from the page or closes the browser application.


If you fill out a web form and then hit the back button of the browser before submitting it, the information you added to that form will be lost. That is, unless the web page implements a mechanism to store that information or (in some cases) the web browser itself caches the contents somehow.

Don’t miss this fact!

The web browser has very limited means of natively persisting information from one page to the next. If a web page needs the browser to “remember” certain things, it needs to manually store that information in browser storage.

The most common form of browser storage is the cookie.

At its simplest, a cookie comprises a name and a value. The cookie is always stored on a specific domain (such as teamsimmer.com) and can only be accessed by users and web servers on that domain.

Sampling of cookies set on the ebay.com domain

There are other storage mechanisms, too, such as HTML5 Storage, IndexedDB, WebSQL, and server-side mechanisms, but cookies are by far the most utilized and, as a result, the most controversial.

Nevertheless, when the following Chapters discuss cookies, most of the commentary applies to all forms of browser storage.

The anatomy of a browser cookie

Cookies can be read and written by JavaScript running in the web browser using a specific JavaScript API available to browser scripts. 

Additionally, when the browser communicates with a web server, the network request can include any cookies written on the domain the web server is responding on. Similarly, the web server can write cookies on its own domain in the response back to the browser.

When a cookie is written (or set), it can be associated with a number of parameters, of which the most significant are:

  • Name (required) – each cookie needs a name with which it can be accessed. There can be more than one cookie with the same name, if they are configured with some different parameters.
  • Value (required) – each cookie needs a value. The value is always stored as an alphanumeric string.
  • Expiration (optional) – the cookie can have a date and time when it will expire. When a cookie expires, the browser automatically deletes it. If the cookie isn’t set with an expiration, it’s considered a session cookie which gets, or should get, deleted at the end of the current browsing session.
  • Domain (optional) – the cookie can be set on a specific domain. However, the cookie can never be set on another site than the one the user is browsing (or the one the web server is responding from). For example, if the user is browsing blog.teamsimmer.com, the cookie can be set on blog.teamsimmer.com or teamsimmer.com, but it can’t be set on www.ebay.com. If a domain isn’t explicitly given, the cookie is written on the exact domain the user or the web server is on.

When cookies are read, the only available information is the cookie name and its value.

What do cookies do?

Cookies persist information from page to page when the user is navigating a website.


Think of a website you have recently logged into. If you were to now visit the website again, you probably wouldn’t need to log in again, as the website “remembers” that you are already signed in. This is thanks to a browser cookie that stores your login state, most likely using an authentication token of sorts.

Similarly, if you were to go to an ecommerce website and add items to your cart, those items would most likely stay in the cart for a day or two as you revisit the site. This is thanks to browser storage.

More insidiously, sometimes you’ll start seeing digital ads reminding you that you left those items in your cart, even if you visit completely unrelated websites. That information, too, is stored in browser cookies.

If there wasn’t a way to persist information like this, every single new page load would require you to log in again and to add the items to your cart again. This would not be a pleasant way to use the web.

Cookies are more than just a web browser utility. Because cookies are included in the network requests to a web server, the server can make use of this information to respond with tailored content.

Don’t miss this fact!

Cookies are a way to persist information from one page to the next in the web browser. They are also included in the network requests to web servers. Servers can parse information in these cookies when determining what type of response to send back to the browser.


If the request to the web server includes a login cookie, the web server can respond with content that is only available to logged-in users. If the request did not have the login cookie, the web server can respond with an error page that says the user needs to log in to view the content.

Deep Dive

First-party and third-party cookies

When discussing cookies, the terms first-party and third-party are often thrown around.

While they have many connotations in different contexts, in the case of cookies they have very specific definitions.

A first-party cookie is one that shares its domain name with the website the user is currently navigating on.

For example, if the user is browsing www.teamsimmer.com, then any browser cookie set on any subdomain under teamsimmer.com is considered a first-party cookie.

A third-party cookie is one that’s set on a different site than the one the user is currently navigating on.

For example, while browsing www.teamsimmer.com, the web page sends a request to fetch a web font from fonts.google.com. Any cookies written on fonts.google.com would be considered third-party cookies in this exchange.

User is navigating…Sends a request to…Party

While first-party storage is rarely limited by browsers, third-party cookies are being gradually shut down by all major browsers.

Third-party cookies can be used for legitimate use cases such as centralized authentication and shared shopping carts. However, they also facilitate some very privacy-infringing activities.

Cross-site tracking is one such activity, and it covers a variety of controversial Topics such as remarketing, audience building, and user profiling across websites.

In the image above, you can see an example of cross-site tracking. The user navigates three completely unrelated domains (shopping.site, news.portal, and social.media). Each of these sites sends a request to tracking.vendor, which then associates the user’s visit to these different sites with their userId cookie stored on the tracking domain.

After this, the vendor that owns tracking.vendor can see that the user with the ID abcd-1234 has visited these three sites. They can then use this information to add the user to an audience that includes people who show an interest in shopping, news, and social media.

Ready for a quick break?

Now’s a good time to take a small break – walk around for 5 minutes and have a glass of water. 😊

Cookies and privacy

On some browsers, cookies can be extremely long-lived.


The Google Analytics client identifier cookie has an expiration of two years. This means that unless the browser itself restricts the lifetime of this cookie somehow, the browser will remember the user as long as they visit the site more than once every two years.

When you combine this with third-party cookies, you essentially have a way for some of the more popular websites of the world (think Google, Facebook) to remember the user’s browsing history for a long, long time.

For this reason, many browsers are committed to removing browser storage features that allow for limitless expiration and/or third-party storage access.

Some browsers go as far as to limit the expiration of even first-party cookies to a point where users might find that their activities are “forgotten” much faster than they’d expect.


On the Safari browser, under certain circumstances first-party cookies can be used to persist information for only 24 hours. That means that the user needs to log in again if they visit the site after more than 24 hours have passed since the last visit.

Storage use is also limited by regulation. In the European Union, the ePrivacy Directive (also known as “The Cookie Law”) requires that websites ask for affirmative consent for any browser storage access that isn’t deemed strictly necessary for the functioning of the website.

Laws like the ePrivacy Directive have resulted in the emergence of consent banners and dialogs which require the user to opt in to browser storage use before they can properly interact with the website.

The web needs persistence

Regardless of how browsers limit or regulations control storage access, the fact remains that the web is essentially stateless.

It would be awkward to build a dynamic website that has no semblance of state.

If you think users could just log in and state could then be stored server-side, remember that login is also a stateful thing. If there is no storage mechanism, then the user needs to log in again with every single page load.

Don’t miss this fact!

If the web server manages the browser user’s state (such as whether the user is logged in or not), you still need a browser cookie or other browser storage mechanism to link the browser user with the logged-in user on the server. Otherwise, the server would not know which incoming network request from the web browser is linked to which user.

The controversy around browser storage emerged when these stateful mechanisms were reappropriated to also persist information that the website didn’t actually need to work properly.

It’s difficult to argue that the cookies set by Google Analytics are somehow as important to a website as a login cookie or a shopping cart cookie, and that’s why regulations strive to establish parameters for handling these different use cases.

Biggest problems emerge when the browser (or regulations) restrict storage access that serves multiple purposes. For example, a login token could also be used as an analytics identifier. It’s thus simultaneously necessary for the site to function but also non-necessary due to its dual use as an analytics identifier.

There’s still a lot of work to be done to resolve these issues. As advertising vendors, browser engineers, regulators, and data collection companies fight it out, it is unfortunately the browser user that ends up paying the price. 

Summary of this Chapter

Well done!

You’ve reached the end of The Web Browser Chapter.

By now, you should have a decent understanding of how the browser works, how the all-important request–response–render process happens, and why cookies and other browser storage mechanisms are so important and so controversial.

Hopefully you can also see why web browsers are so fundamental for technical marketers, too.

The web is the main technology in digital marketing, even if native mobile apps are increasingly important. Your efficiency in digital analytics, search engine optimization, paid media, online privacy, and experimentation directly correlates with how well you understand these underlying mechanisms.

All the subsequent Chapters of this Handbook will refer to the information shared in the three Topics that you just read. The better you understand the terminology and concepts around web browsers, the easier will your life as a technical marketer be.

Key takeaway #1: Cookies are written on a domain

Cookies are always written on a specific domain. If you navigate to a web page, then that web page can only access cookies written on its domain (with or without subdomain prefixes). Similarly, if the page dispatches a request to a web server, then that server can only access cookies written on the domain the request was sent to.

Key takeaway #2: Third-party vs. first-party

First-party context means that a cookie is accessed on the site the user is currently navigating. For example, you are now browsing the domain handbook.teamsimmer.com. Any cookies written on the site teamsimmer.com can be accessed in first-party context. Third-party context means that a cookie is accessed on a site that you are not navigating. For example, if this page loaded a frame with content from google.com, that frame could access cookies on google.com but not those on teamsimmer.com.

Key takeaway #3: The web is stateless

Cookies and other browser storage serve a very important purpose on the web. Without some type of storage, nothing would persist from one page to the next as you navigate the web. Without browser storage, your shopping carts would be empty all the time, you would be logged out constantly, and much of the browsing experience on the web would be broken.

Quiz: Cookies And Other Browser Storage

Ready to test what you've learned? Dive into the quiz below!

1. Which of the following use cases would not need a browser cookie (or other similar storage mechanism)?

2. Which of the following are attributes of a cookie that can be configured when the cookie is written? Select all that apply.

3. What is a commonly used term for the ePrivacy Directive in Europe?

Your score is


What did you think about this topic?

Thanks for your feedback!

Unlock Premium Content

Simmer specializes in self-paced online courses for technical marketers. Take a look at our offering and enroll in one or more of our courses!

Online course

Web Browsers And Tracking Protections

Simmer’s online course teaches you all you need to know about web browsers and their tracking protection mechanisms.

0/27 Topics completed

Dedication pays off!

Complete all topics to claim your certificate.

Next Chapter