The difference between webstorage and cookies

Sessionstorage and Localstorage are provided by the HTML5 Web Storage API to easily save data between Web requests. With local data, you can prevent data from being passed back and forth unnecessarily between browsers and servers. Cookies

Cookies are passed back and forth between the browser and the server, the main scenario: Keep the login and keep the last viewed page browsing count ads tracking the status of the cart

how cookies are effective.
When a browser receives a Set-cookie header from a Web response to a page request, the cookie is created:

http/1.1 OK
content-type:text/html
set-cookie:page_loaded=25; expires=wed, June 2021 10:18:14 GMT

The browser receives the HTTP 200 code that indicates a successful response and the content type of the response. The Set-cookie head is also received and a cookie is created:

Name	Value	Expires
page_loaded	25	Wed, June 2021 10:18:14 GMT

Unless the Wed is refreshed before 2021 10:18:14, the cookie will be invalidated and removed by the browser after that. If it is not terminated, all future requests for the site will carry a similar message to the head:

get/spec.html http/1.1
Host:www.example.org
cookie:page_loaded=25;

Cookies have a bad reputation for potential privacy and security implications. They are vulnerable to security problem attacks, such as CSRF (Cross site Request forgery) for critical attack vectors, XSS (Cross site scripting attacks), and session hijacking. A diligent and professional developer may not put a lot of security detail into cookies or implement a series of methods to mitigate these possible forms of attack. WebStorage

HTML5 introduces the Web storage as a substitute for cookies, which can be stored in two types: local and session:
defects in Web Storage

Data is stored in simple strings, and operations require different types of objects, such as booleans,objects,ints and floats, to be stored.

Default 5MB storage limits, and if necessary, a user can allow more storage.

Can be disabled by user or system administrator

Complex data collection storage can be a slow Web Storage Advantage

APP can be used again online or offline

Have a simple and easy to learn API

Ability to use event hooks for browsers, such as offline,online,storage change

Easier to manage than cookies, no extra requests for header data

Provides greater space to store the growing number of complex data Web Storage APIs

The Web Storage API is easy to learn, and it contains only four methods:

Sessionstorage, Localstorage, cookies are data stored on the browser side, where the concept of sessionstorage is very special, introducing a "browser window" concept. Sessionstorage are data that is always present in the same window (or tab) of the same origin. That is to say, as long as the browser window is not closed, the data still exists even if the page is refreshed or goes to another page. When the window is closed, the sessionstorage is destroyed. At the same time "independent" open different windows, even the same page, the Sessionstorage object is different.
The benefits of Web Storage: Reduce network traffic: Once the data is stored locally, you can avoid requesting data from the server, thereby reducing unnecessary data requests and reducing the unnecessary data transfer between browsers and servers. Rapid display of data: Good performance, from local reading data than through the network from the server to obtain data much faster, local data can be obtained instantly. Plus the page itself can have a cache, so the entire page and data are local, you can immediately display. Temporary storage: Most of the time the data needs to be used only when the user browses a group of pages, and the data can be discarded after the window is closed, which is very convenient to use sessionstorage. Event Storage

Sessionstorage and Localstorage have the same method storage event, which cannot be canceled in the handler function of the stored event. Storage events are just a notification that the browser gives you after the data change occurs. The storage event is triggered when SetItem (), RemoveItem (), or the clear () method is invoked, and the data really changes. Notice that the condition here is that the data really changed. In other words, if the current storage area is empty, you can call clear () without triggering the event. Or you can set a value that is the same as an existing value by SetItem (), and the event will not be triggered. When the storage area changes, it is triggered, which contains a number of useful properties:

Storagearea: Represents a storage type (session or local)
Key: Key that has changed the item
Oldvalue:key's original value
New value for Newvalue:key
url*: The URL where key changes occur
* Note: The URI attribute is in the early specification of the URL property. Some browsers were released earlier and did not include this change. For compatibility reasons, you should check for the existence of the URL property before using it, and if there is no URL attribute, you should use the URI attribute
If the clear () method is invoked, the key, OldValue, and NewValue are all set to NULL.

PS. Both store and read in Firefox and Chrome are normal, but there seems to be a problem with the triggering of the storage event, which does not trigger the window's storage event after its own page SetItem, but it also accesses a.html and b.html , the SetItem in page a can trigger the storage event of window in page B, the same setitem on page B can trigger the storage event of window in page a . In IE9, the page itself set value can trigger the current page of the storage event, the same current page set value can trigger the same "origin" under the other page window storage event, this seems to make more people think more.

Reference:
MDN

Storage Event Resolution