A cookie jar is a client's cookie store plus the rules that decide which stored cookies belong on each outgoing request. It processes Set-Cookie response headers, retains each cookie's domain, path, expiry, and security attributes, then constructs the Cookie header for matching requests.
RFC 6265's storage model includes the cookie's name, value, expiry, domain, path, creation and access times, and flags such as host-only, Secure, and HttpOnly. Two cookies can share a name while differing by domain or path, so a plain dictionary keyed only by name loses information and can send the wrong state.
Session cookies normally disappear when the client session ends; persistent cookies carry Max-Age or Expires, though a client can evict them sooner. A new cookie with the same name, domain, and path replaces the previous one, and an already-expired replacement deletes it.
Before a request, the jar filters cookies by host or Domain scope, Path, expiry, and the Secure flag. HttpOnly prevents page JavaScript from reading the cookie but does not stop the browser from sending it on matching HTTP requests. Cookie scope does not use ports as an isolation boundary.
Do not copy an entire Cookie header across domains or scrape jobs. That can leak authentication state, merge independent visitors, and make results depend on an unrelated prior request. Give each intended identity its own jar and persist it only when the workflow explicitly requires continuity.
Cookie jars are required for login flows, locale preferences, carts, consent state, and bot challenges that set a token before the next request. They also create hidden state: the same URL can return different content depending on what earlier responses stored.
Record which session produced each result, clear state between unrelated runs, and avoid logging secret cookie values. When debugging, compare a fresh jar with the persisted one and inspect Set-Cookie metadata rather than pasting raw credentials into logs or source code.
How Crawlora handles this
When a Crawlora platform endpoint provides the needed data, callers do not have to reproduce the source site's cookie-backed interface flow. Custom direct crawlers still need isolated cookie jars for any source workflow that spans requests.
Related reading
Glossary
FAQ
No. Correct selection also requires domain, path, expiry, Secure, HttpOnly, host-only, and creation metadata. The same name can validly exist at several scopes.
No. Sharing merges session state and can leak credentials or preferences across identities. Use one isolated jar per intended browser or account context.
No, but the browser still sends it on matching HTTP requests. HttpOnly limits script access; it does not remove the cookie from the request-selection rules.
Beyond Cookie Jar, Crawlora's own docs cover the rest of the stack — browse the APIs, test a request in Playground, and move from scraping infrastructure work to production data workflows.