In a browser, what exactly does reading `document.cookie` give you, and how would you extract the value of a single cookie named `theme` from it?

## What the property actually is `document.cookie` is an accessor property on `Document` with both a getter and a setter, and the two do completely different jobs. The getter serialises the browser's cookie store for the current document into **one string**. The setter parses **one cookie** out of a string you assign. Nothing about the API is object-shaped: there is no `document.cookies` collection, no `.get(name)`, no length. The returned string is a list of `name=value` pairs separated by a semicolon and a space, with no trailing separator: ```js document.cookie; // "theme=dark; lang=en; cart=a%2Cb" ``` If no cookie is readable, you get the empty string `""` — not `null`, not `undefined`. ## What the browser filters out before you see it The getter is a filtered view, and four filters apply: - **Scope matching.** Only cookies whose domain and path match the current document's URL are included. A cookie stored for `Path=/admin` simply is not there while you are on `/home`. - **`HttpOnly`.** A cookie the server marked `HttpOnly` never appears in `document.cookie`, no matter what. This is usually the session cookie — the one you most want to read is the one you cannot. - **`Secure` on an insecure page.** A `Secure` cookie is withheld from a page served over plain `http:`. On `https:` it reads normally; `Secure` restricts transport, not scripting. - **All attributes.** The getter emits names and values only. `Expires`, `Max-Age`, `Path`, `Domain`, `Secure`, `SameSite` are write-only from JavaScript's point of view: you can set them, and you can never read them back. There is no way to ask `document.cookie` "when does this expire?" or "which path is this scoped to?". A consequence of the last two points: if two cookies share a name but differ in path (`/` and `/app`), both appear in the string as identical-looking `name=value` entries and you cannot tell which is which. ## Parsing it correctly ```js function readCookie(name) { const prefix = encodeURIComponent(name) + '='; const hit = document.cookie .split('; ') .find((pair) => pair.startsWith(prefix)); return hit ? decodeURIComponent(hit.slice(prefix.length)) : undefined; } ``` Three details matter here. **Match the whole name**, anchored with `startsWith` after splitting — a bare `document.cookie.includes('id=')` also matches `uid=` and `session_id=`. **Split the value at the first `=` only**, because a value may legitimately contain `=` (base64 padding is the usual culprit). And **decode**: cookie values cannot carry `;`, `,`, whitespace or control characters literally, so the near-universal convention is to `encodeURIComponent` on write and `decodeURIComponent` on read. The platform does not do this for you — `document.cookie` hands back exactly the bytes stored. ## Why the string can be surprisingly large Every cookie visible here is also attached by the browser to matching requests, so the cookie jar is request overhead on every navigation and fetch, not just client state. Browsers cap roughly 4 KB per cookie and a few dozen per domain; exceeding the cap silently drops the write rather than throwing. That is the main argument for not using cookies as a general client-side store when the server does not need the value. ## Reading is synchronous and re-parses each time The getter builds the string on every access, so a loop that reads `document.cookie` once per iteration is doing repeated work; read it once into a local variable and parse that. It is also fully synchronous on the main thread and unavailable in workers, which is precisely the gap the newer promise-based cookie API was designed to close. ## The practical summary Treat `document.cookie` as a serialised, filtered, attribute-free snapshot of the subset of cookies this document is allowed to see. Anything you need to know beyond a name and a value — expiry, scope, whether it exists at all in the HttpOnly case — has to come from somewhere other than this property.