Cookies on a website are small pieces of text that a site asks your browser to store and send back each time you return. They are how a site remembers that you are logged in, what is in your basket, which language you chose, and, for analytics and advertising, that you are the same visitor as last time. A cookie is data, not a program: it cannot run on your device or read your files.
This guide explains website cookies for visitors first and site owners second: the types, how a site sets them, how to see them and whether they are safe. If you run a site, the rules on asking permission are in the guide to what cookie consent laws require.
Quick answer
- A cookie is a name and a value (for example
lang=en) that your browser stores for one site and sends back on every request to that site. - Uses: keeping you logged in, holding a shopping cart, remembering settings, and recognising you for analytics and advertising.
- First-party cookies belong to the site in the address bar. Third-party cookies belong to another domain loaded inside the page, such as an ad network, and can follow you across sites.
- Session cookies disappear when you close the browser; persistent cookies stay until an expiry date, at most 400 days in Chrome.
- Browsers differ: Safari blocks third-party cookies by default and Firefox isolates them per site; Chrome still allows them unless you switch them off.
- Safe? Cookies cannot carry viruses. The real concerns are tracking, which you can refuse, and stolen login cookies, which sites prevent with security flags.
What are cookies on a website?
HTTP, the protocol behind the web, forgets each request as soon as it is answered. Cookies fix that: the server attaches a small note to its answer, your browser keeps it and hands it back with every later request to the same site. MDN's guide "Using HTTP cookies" defines a cookie the same way.
A cookie holds very little: a name, a value and a few settings such as when it expires and which pages it applies to. RFC 6265, the standard that defines cookies, asks browsers to support at least 4,096 bytes per cookie, so a cookie is usually an ID or a short setting, not your personal details. The ID points to information the site keeps on its own server.
What are website cookies used for?
MDN groups cookie uses into three jobs:
| Use | What it does | Typical examples |
|---|---|---|
| Session management | Keeps you logged in and remembers your actions between pages | Login session, shopping cart, CSRF token on forms |
| Personalisation | Remembers choices you made | Language, currency, dark mode, your cookie banner choice |
| Tracking | Recognises you across visits or sites to measure and advertise | Google Analytics _ga, Meta Pixel _fbp, ad network IDs |
The first two serve you directly. The third serves the site and its advertising partners, which is why cookie banners exist: in the EU and UK, tracking cookies need your permission first.
First-party vs third-party cookies
The difference is who the cookie belongs to, measured against the site in your address bar.
| First-party cookie | Third-party cookie | |
|---|---|---|
| Set by | The site you are visiting (shop.example) | Another domain loaded in the page (ads.example) |
| Sent back to | That site only | The other domain, on every site that embeds it |
| Typical uses | Login, cart, settings, first-party analytics | Cross-site advertising, retargeting, some embeds and chat widgets |
| Default in Safari and Firefox | Allowed | Blocked (Safari) or kept separate per site (Firefox) |
| Default in Chrome | Allowed | Allowed, unless you block them in settings |
The same company can be both. A social network's cookies are first-party when you visit it directly and third-party when its "Like" button is embedded on a news site.
"First-party" does not mean "not tracking". Google Analytics' _ga and the Meta Pixel's _fbp are first-party cookies: the tracking script runs on your page and stores the ID under your domain. Since browsers started restricting third-party cookies, many trackers have moved to this pattern, so a site can have no third-party cookies at all and still track visitors.
What are third-party cookies?
Third-party cookies are cookies set by a domain other than the one in your address bar, through an image, script or iframe the page loads from that domain. Because the browser sends the cookie back to that domain wherever it appears, a company embedded on thousands of sites can recognise one browser on all of them and build a profile of the pages it visits. MDN notes that this is exactly why browser makers have moved to block them.
They also have legitimate uses, such as a payment form, an embedded map or a chat widget that remembers your conversation. Those break when third-party cookies are blocked, which is why the cookie flags guide warns against building a login or payment flow that depends on one.
Does Chrome still allow third-party cookies?
Yes. As of September 2026, the major browsers treat them differently:
- Safari has blocked all third-party cookies by default since Safari 13.1 in March 2020, as part of Intelligent Tracking Prevention (WebKit blog, "Full Third-Party Cookie Blocking and More").
- Firefox has turned on Total Cookie Protection for all users by default since June 2022. Every site gets its own separate cookie jar, so a third-party cookie set on one site cannot be read on another (Mozilla blog).
- Chrome allows third-party cookies by default in normal windows and blocks them in Incognito. In July 2024 Google said it would not deprecate them. On 22 April 2025 it added that it would keep the current approach, a setting in Privacy and security, and "will not be rolling out a new standalone prompt for third-party cookies". On 17 October 2025 it retired most Privacy Sandbox technologies meant to replace them, including Topics and Protected Audience (Privacy Sandbox blog).
What Google kept is CHIPS, partitioned cookies. A third-party cookie set with the Partitioned attribute (which also requires Secure) gets a separate jar per top-level site, so an embedded chat widget can remember you on one site without linking that to other sites. MDN lists partitioned cookies as working across current browsers since December 2025. If you build an embed that needs a cookie, this is the durable way to do it.
Session vs persistent cookies
The second distinction is how long a cookie lives.
- Session cookies have no expiry date. The browser deletes them when the session ends, usually when you close it. Some browsers restore sessions on restart, and with them session cookies, so "when you close the browser" is not guaranteed.
- Persistent cookies carry an
Expiresdate or aMax-Agein seconds and survive restarts until then, or until you clear them.
Browsers put their own limits on top. Chrome caps any new cookie at 400 days, whatever the site asks for, and the draft update to the cookie standard adopts the same 400-day limit. Safari caps cookies written by JavaScript at 7 days. So a _ga cookie set for 2 years lives about 13 months in Chrome and a week in Safari.
Lifetime matters for privacy rules too. EU regulators such as the French CNIL expect consent-based cookies to expire within 13 months, and getReport's cookie scan flags longer ones:
How does a website set a cookie?
There are two ways, and both end up in the same place in the browser.
From the server, with a Set-Cookie header on the response:
Set-Cookie: session=a3fWa9; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600From JavaScript on the page, with document.cookie:
document.cookie = "lang=en; Path=/; Max-Age=31536000; SameSite=Lax";The part after the first semicolon is attributes, and they decide where the cookie goes and who can read it:
DomainandPath: which hosts and paths get the cookie back. WithoutDomain, only the exact host that set it does.ExpiresorMax-Age: makes it persistent.Secure: only sent over HTTPS.HttpOnly: hidden from JavaScript, so an injected script cannot read it.SameSite: whether it is sent on requests coming from other sites.Partitioned: the CHIPS opt-in described above.
The standard behind all of this is RFC 6265 from 2011. Its replacement, known as RFC 6265bis, adds SameSite and the 400-day limit; as of September 2026 the IETF has approved it and it is in the RFC Editor's queue, without an RFC number yet. The guide to cookie flags explains Secure, HttpOnly and SameSite and how to set them in PHP, Express, nginx and WordPress.
How to see the cookies a website sets
As a visitor, click the icon at the left of the address bar. Chrome, Edge, Firefox and Safari show the site's cookies and data there or in the site settings it links to, with an option to delete them.
As a developer, open the browser's developer tools: Application → Storage → Cookies in Chrome and Edge, the Storage tab in Firefox, and the Storage tab of Web Inspector in Safari. Each cookie shows its domain, expiry and flags. Use a private window to see what a first-time visitor gets.
For a before-and-after view, use a scan:
The cookie scanner opens your page from Frankfurt in a fresh Chromium browser with no cookies, records every cookie and request, then finds the banner's accept button, clicks it and records what appears afterwards. Each cookie is listed with its name, lifetime and whether it is first-party or third-party, and requests are matched against 25 well-known analytics, advertising and session-recording services. Banners inside iframes or with unusual button labels can be missed; you then get the before-consent list only.
Are website cookies safe?
For your device, yes. A cookie is a short piece of text, not a program, so it cannot install anything, run code or read your files. A site can only read its own cookies; it cannot see the cookies other sites have set.
The real questions are about privacy and accounts:
- Tracking. Advertising and analytics cookies record what you do. You can refuse them in a site's cookie banner, block third-party cookies in your browser settings, or clear cookies regularly. Refusing them rarely breaks a site; refusing necessary cookies, such as login cookies, will.
- Session theft. Whoever holds a login cookie is treated as logged in. Well-built sites protect those cookies with
Secure,HttpOnlyandSameSite, and you protect them by avoiding malware and logging out on shared computers.
What website cookies mean for site owners
In the EU, Article 5(3) of the ePrivacy Directive requires consent before a site stores or reads information on a visitor's device, with an exemption for what is strictly necessary to provide a service the visitor asked for. The UK's PECR has the same core rule, with some new exceptions since February 2026. What counts is the purpose, not whether a cookie is first-party or third-party: a first-party analytics cookie needs consent in the EU, while a payment provider's cookie that checkout needs does not. The pillar guide on cookie consent requirements covers the EU, UK and US rules in full.
The most common technical failure is a banner that asks the question while the tags fire anyway. If your scan shows _ga, _fbp or similar before anyone clicks, the guide to cookies set before consent shows how to make Tag Manager and your consent platform wait, and the guide to a cookie banner that passes covers the reject button and consent lifetime.
Questions people ask
What are third-party cookies?
Third-party cookies are cookies set by a domain other than the one in your address bar, usually through an ad, tracking script or embedded widget on the page. Because your browser sends them back to that domain on every site that embeds it, they let one company recognise you across many sites. Safari blocks them by default, Firefox isolates them per site, and Chrome still allows them unless you turn them off.
What is the difference between first-party and third-party cookies?
A first-party cookie belongs to the site you are visiting and is only sent back to it; a third-party cookie belongs to another domain loaded inside the page and is sent to that domain wherever it appears. First-party cookies run logins, carts and settings. Third-party cookies mostly serve cross-site advertising. First-party cookies can still track you, as Google Analytics' _ga does.
Should I accept cookies on a website?
Accept what you need and refuse the rest. Necessary cookies, such as login and cart cookies, need no permission and are set anyway. Analytics and advertising cookies are optional: refusing them rarely breaks a site and limits how much you are tracked. In the EU and UK, a site must make refusing as easy as accepting and must work without optional cookies.
Can cookies on a website give my computer a virus?
No. A cookie is a short piece of text that your browser stores and sends back, not a program, so it cannot run code, install software or read your files. The risks are different: tracking by advertising cookies, and someone stealing a login cookie to take over your session. Security flags on the site's side and up-to-date software on yours address the second.
Is Chrome still phasing out third-party cookies?
No. Google said in July 2024 that it would not deprecate third-party cookies in Chrome, and in April 2025 that it would not add a separate prompt either; users keep the existing setting in Privacy and security. In October 2025 Google retired most Privacy Sandbox replacements but kept CHIPS partitioned cookies. Safari and Firefox still restrict third-party cookies by default.
Can a website read cookies set by other websites?
No. Your browser sends each cookie back only to the domain that set it, and scripts on a page can read only that page's own cookies, and not even those when they are marked HttpOnly. Cross-site tracking works differently: the same third party is embedded on many sites and reads its own cookie on each, which is what browsers now block or partition.
What is the difference between a session cookie and a persistent cookie?
A session cookie has no expiry date and is deleted when the browser session ends, usually when you close the browser. A persistent cookie has an Expires date or Max-Age and survives restarts until then. Chrome caps persistent cookies at 400 days and Safari caps those set by JavaScript at 7 days, whatever the site asks for.