How Do Cookies Work from JS?

Cookies are read and written through the document.cookie property. Writing is a string assignment, and reading gives you back a single string containing every cookie for the current page, formatted as name and value pairs separated by semicolons.

// document.cookie only exists in a browser.
if (typeof document !== "undefined") {
  document.cookie = "theme=dark; path=/; max-age=3600; SameSite=Lax";

  console.log(document.cookie);   // "theme=dark"

  // Cookies come back as one string, so you parse them.
  const readCookie = (name) => {
    const match = document.cookie.match(new RegExp(`(?:^|; )${name}=([^;]*)`));
    return match ? decodeURIComponent(match[1]) : null;
  };

  console.log(readCookie("theme"));   // "dark"
} else {
  console.log("No document in this runtime - open a browser console to try it.");
}

Because the whole thing is one string, you need a helper to read a single cookie by name, and the regular expression in the example is the standard way to do it. The decodeURIComponent call matters because the cookie API encodes special characters automatically when you write them, so the value you read back is still percent encoded.

When you write a cookie, the attributes come after the value, separated by semicolons. The path attribute decides which paths on the site can see the cookie, and it defaults to the directory of the current page, which surprises people who then cannot find their cookie elsewhere. The max-age attribute gives it a lifetime in seconds, and the expires attribute does the same with a date. The SameSite attribute controls whether the cookie is sent on cross-site requests, and the Secure attribute restricts it to secure connections.

Two limitations to remember. A cookie set with the HttpOnly attribute is invisible to JavaScript, which is the correct choice for session tokens. And document.cookie cannot see those cookies at all, so they are simply not listed.

You cannot delete a cookie directly. You set it again with an expiry in the past, which tells the browser to remove it.

if (typeof document !== "undefined") {
  document.cookie = "session=abc123; path=/";

  // To delete a cookie, set it again with an expiry in the past.
  document.cookie = "session=; path=/; max-age=0";

  console.log(document.cookie.includes("session="));   // false
} else {
  console.log("No document in this runtime - open a browser console to try it.");
}

The attributes have to match. A cookie is identified by its name together with its domain and its path, so if you set the cookie with a path of slash and then try to delete it with a path of the current directory, you are creating a second cookie instead of removing the first. This is the single most common reason a cookie appears to be undeletable.

There is one more wrinkle with the max-age attribute. When you pass zero it means expire immediately, and when you pass a negative number the same thing happens, so both work. The expires attribute with a date in the past works as well, and some code uses that form for older browser support.

Two related points for an interview. Cookies are sent with every request to the matching path, which is why a large cookie on every request slows the site down and why you should keep them small. And because cookies are sent automatically, they are the reason for cross-site request forgery. Any state-changing request should be protected by something other than a cookie alone, and the SameSite attribute is the modern defence.

There are five flags and attributes that matter, and each one closes a specific hole.

The HttpOnly attribute stops the cookie from being read by JavaScript. Any script that ends up running on your page, including one injected through a cross-site scripting bug, cannot read the value. This is why session tokens belong in an HttpOnly cookie rather than in local storage. The trade-off is that your own code cannot read it either, which is why the server sets it and the server reads it.

The Secure attribute restricts the cookie to secure connections, so it is never sent over plain HTTP. The SameSite attribute controls cross-site sending, and setting it to Lax or Strict is the main defence against cross-site request forgery. The Path and Domain attributes narrow where the cookie is sent, which limits both the performance cost and the exposure.

Then there is the size and content side. Cookies travel with every matching request, so they should be small, and they should never contain anything sensitive that the page does not need, because a value that is readable by JavaScript is readable by any injected script.

Two more practical points. Cookies are shared across tabs of the same origin, so if one tab logs out, the session cookie change affects the others, which is a common source of confusing behaviour. And because the cookie is sent automatically, a state-changing request that relies on the cookie alone is forgeable, so those requests need their own protection, usually a token that the script has to read and send explicitly.