What Is a Cookie? – Definition and How It Works

Learn what an HTTP cookie is, how Set-Cookie and attributes work, the difference between session and persistent cookies, and why they matter for automation.

A cookie is a small piece of data a server asks a client to store and send back on later requests. It exists because HTTP itself is stateless: without cookies, every request would arrive with no memory of the last one.

1. What Is a Cookie?

A cookie is a name-value pair with attributes controlling where and how long it applies.

• Key idea: the server hands the client a token of state and the client returns it automatically.
• Mechanism: Set-Cookie in a response, Cookie in subsequent requests.
• Goal: carry sessions, preferences, and consent across otherwise independent requests.

Example

Set-Cookie: session=abc123; Path=/; Max-Age=3600; Secure; HttpOnly; SameSite=Lax

2. The Attributes That Matter

HttpOnly and SameSite are the two that most directly reduce common attacks, and both are set by the server rather than chosen by the client.

3. Session Versus Persistent

• Session cookies carry no expiry and are discarded when the browser session ends. Typical for login state.
• Persistent cookies carry an expiry and survive restarts. Typical for preferences, consent records, and long-lived sign-in.

A cleared cookie jar therefore logs a user out of the first kind and forgets their preferences from the second.

4. First-Party and Third-Party

A cookie set by the site in the address bar is first-party. One set by an embedded resource from another domain is third-party, and those are the ones used for cross-site tracking — which is why browsers increasingly restrict or block them by default.

SameSite is the mechanism that governs this: a cookie marked Strict never accompanies a cross-site request, Lax allows it on top-level navigation, and None permits full cross-site use but requires Secure.

5. Why Cookies Matter for Automation

Any workflow spanning more than one request needs the cookie jar preserved. Practical consequences:

• Logins persist only if cookies are stored between requests, which HTTP client libraries do only when a session object is used.
• Consent banners are usually satisfied by a cookie; discarding it means facing the banner on every page.
• Anti-bot clearance is often recorded as a cookie, so a client that drops it repeats the challenge each time.
• Session isolation — separate tasks need separate jars, or state from one contaminates another.

6. Common Misconceptions

• "Cookies are executable." They are inert data; the risk is what they authorise, not what they run.
• "HttpOnly means encrypted." It only hides the cookie from page scripts. Transport protection is TLS.
• "Deleting cookies makes you anonymous." Many other signals identify a client, and cookies are only one linkage mechanism.
• "Third-party cookies are gone." Restrictions vary by browser and configuration; behaviour is not uniform.

7. Real-World Examples

• Keeping a shopping basket across page loads.
• Remembering a language choice so a site renders in the right locale.
• Recording that a consent dialog was answered.
• Carrying a challenge-clearance token so subsequent requests are not re-tested.

8. Summary

A cookie is server-set state stored by the client and returned automatically, with attributes governing scope, lifetime, and exposure. It is what makes a stateless protocol able to support sessions.

For anything automated, preserving the jar is not optional: logins, consent, and clearance all depend on returning what the server previously set.

Potential Related Glossary

• Browser Fingerprints
• Headless Browser
• Parsing
• Web Crawling