Http Cookies 🍪 is a 25-year-old simple string store. Explained in 3 mins.

I ❤️ cookies. They have been around since 1994. The world of Inter-web today would look very different if we didn't have cookies.

Without cookies, the web would be a static and boring place, where everybody would be reading the same news feed on dev.to.

In fact, this post wouldn't even get published if not because of cookies.

So, what are Cookies?

Cookies are simple key-value data that your browser stores. E.g., This line below is a cookie.

sessionId=123

A cookie can be created/updated/deleted by

• Your browser via Javascript code document.cookie, or
• The server via set-cookie response headers

But, cookies are private to domain, meaning only the client-side code running in the domain can access it. E.g., when you open twitter.com in browser, its javascript cannot see the cookie below.

// This cookie is only accessible by dev.to's javascript when running on the browser
sessionId=123; domain="dev.to";

The browser automatically sends all cookies of a domain as part of the requests to the domain's server. E.g., with the example above, each request to dev.to will include that cookie. This allows dev.to's server to read the cookie value from the request, and associate the request with a previous visitor (aka session).

Just like any cookies 🍪 you can buy in stores. They expire.

// expires at time
sessionId=123; expires=Thur, 5 Sep 2019 12:34:56 UTC
// expires in a year
sessionId=123; max-age=31536000
// expires when browser closes
sessionId=123;

Sometimes there are too many cookies to send for a certain domain, and we can use path to send only cookies that match a path.

// only send this cookie when current location is "/newsfeed/*"
sessionId=123; path="/newsfeed"

Why Cookies rock?

Though invisible to most users, it's most famous for supporting sessionIds (or similar names), which is a fundamental building block for enabling user-identity on web.

Taking dev.to as an example. First time I accessed dev.to, their server set a cookie with name _PracticalDeveloper_session to my browser. Since then, every time I go to dev.to, I present the _PracticalDeveloper_session cookie value in each http request to their server, and that proves me as techbos. This allows dev.to server to send me MY personal newsfeed and notifications, not @ben's.

See my dev.to cookies in image below:

What are Cookies not so great for?

First of all, you can't eat them 🙃 .

Besides that, cookies are bad for storing arbitrary data in the browser, because:

1. It has some serious size limitations (see bottom).
2. They are automatically included in every single request sent to the server. The more data in cookies, the more bandwidth your request will consume.

What are Alternatives to Cookies?

For supporting sessionIds, there is no alternatives to cookies in web's world.

For storing data in the local browser, there are three choices:

1. LocalStorage: persisted until user clears cache.
2. Session Storage: persisted until browser or tab is closed.
3. IndexedDB: Useful for storing large amount of structured data. Pretty complex low-level stuff.

However, do NOT store sensitive information (e.g., tokens, passwords, etc.) using above options as they are not meant as secure data stores.

Don't touch my Cookies!

The TL;DR version is to use Secure and HttpOnly to protect your cookies.

sessionId=123; Secure; HttpOnly;

Secure ensures the cookie is only available to server when accessing the site using https. Thus preventing man-in-the-middle.

HttpOnly ensures the cookie is NOT accessible by javascript. Thus preventing XSS (cross-site scripting), aka bad guy running their smelly js on your webpage.

How big a Cookie can I make?

Each browser has slightly different implementation over how many cookies per domain can be stored at a time, and what the max data size for each cookie. A general rule of thumb is each cookie shouldn't exceed 4KB of data, and the total size of all cookies for one domain shouldn't exceed 4KB either.