Reactive Stack

Frontend Development

Why Using Cookies in React.js

By Benoit Tremblay - Published 2018/10/22

When I began learning React.js in 2014, I was looking for a way to persist data for the user and at that time. The obvious answer was to use cookies on the client because it was the only supported answer for all major browsers. It was when supporting IE 6 was still a thing. However, because so few people were doing it, they were no prescribed way for handling cookies in React.js. This is why in March 14th 2015, I’ve released the first version of react-cookie. More than 3 years and a half latter, it grew into more than 100,000 weekly downloads for two libraries: universal-cookie for any JavaScript user and react-cookie for making React.js user's life easier.

While spending a lot of my time playing with cookies, I’ve learned quite a lot and would like to share my insight with you on when and why you should use them and why you should not.

Your cookies are sent with all your requests

One of the most important thing to know about cookies is that they are automatically included every time you navigate to a page. It might be useless information for your server if you are not aware of that. Do not use cookies if you don’t want that! However, it can also be very useful if you understand how that works. One of the most common scenario is when you are doing server-side rendering (SSR) and authentication.

Server-Side Rendering

SSR is a very popular approach in React.js where you render statically on the page how your Web app will look like at the page load. That way, your user can see the application a lot quicker until the real app is loaded. However, if your user is already logged in or have custom settings, your server needs to know about everything. This is where cookies are becoming very handy. By using a library like universal-cookie-express and react-cookie, you can automatically load the user cookies within your code and when doing the rendering on the server-side, you could get and save cookies on the server the same way you would do on the client.

Authentification / Session ID

Saving authentication tokens or session ID within a cookie is a good idea because you most likely need them everywhere. Having them sent with every request is handy because it becomes one less thing to think about. If you also want to include them within your AJAX requests, make sure to use the credentials: 'include or same-origin' if you are using fetch or withCredentials: true if you are using XMLHttpRequest. Otherwise, your cookies might not be included with the request if you are using fetch or XMLHttpRequest and your API is on a different domain.

Limiting the scope of your data

This is by far the less understood part of cookies and their default behaviour. By default, the scope of your cookie is the current path. If you are saving a cookie at, you will be able to access it if you are at that exact page or sub-page (example However, you will not be able to access it on the home page or any other page not starting by /cat. If you are a beginner and don’t know about that, it might be frustrating to see your cookies appear and disappear. However, the solution is easy. If you wish to make your cookies available everywhere, just set path: '/' when saving your cookies. However, you also have the option to make them available only on a sub-set of your pages. If your Website is not a Single Page Application, you can limit the scope of your cookies to the minimum you need them.

You can also share your cookies between sub-domain by using domain: ‘' (with a leading dot). You can also limit your cookies to a specific sub-domain by making it explicit. If your cookies have an authentication token, it is also a good idea to limit them to only HTTPS by setting the secure: true flag.

The final scope you can use that is very interesting for security purpose is HTTP-only cookies. Those, you can’t read with JavaScript, but you can include them by using the credentials property. That way, if your site has a XSS attack, it cannot read the cookie value. However, you should know that CSRF attacks are still possible.

Have an expiration date by the browser

Finally, the last benefit of using cookies is the explicit expiration date. You can tell the browser for how long your cookie should live and when it should expire. That you, you can make sure the user has to re-login or doesn’t use an expired authentication token. The same behaviour could be replicated by saving a date in your local storage, but it is nice to have something to enforce it.

Using the local storage

If you don’t care about any of that, you might as well use the local storage. It is supported by every browsers. Instead of having a limit of 4K per cookie, your local storage has an overall limit of 5MB.

If you wish to learn more about cookies in JavaScript and React.js, visit my GitHub

Did you enjoyed my article?

Join my Weekly Newsletter About

How to Build Amazing Softwares and be Productive

Where should we send the newsletter?