This is the second post of the series where I’m trying to focus on the Storage options – inside the Applications tab in Chrome browser. In the first part, I blogged information about localStorage, it’s use and properties.

In this post, I’ll focus on SessionStorage, which is another of the Web Storage API’s that is provided to use after HTML5. We’ll try to see what it is and how it is different from localStorage.

Session Storage

Another option provided by the Web Storage API ‘s is the concept of sessionStorage. You can see this option in the same menu item as localStorage in Chrome Applications tab – right below localStorage.

The sessionStorage object (window.sessionStorage ) stores data that persists data only for the active session of the browser tab. What does this mean?

To be precise this means – what ever data that you store in sessionStorage will persist even when the page is reloaded ( or reload event is fired). The data is removed once that browser session is terminated or closed.

When you open a page in a new tab or window, the web browser creates a new session.

The sessionStorage items are not accessible across multiple tabs – which means that if open multiple tabs or windows with the same URL, then there will be separate sessionStorage object created per tab or window, and the tabs cannot access these items.

But these data is shared if there are iframes in the same tab (assuming they come from the same origin).

Key Pointers

  • sessionStorage limit is always less than the localStorage limit and also less frequently used.

  • Data stored in sessionStorage object is per-origin . What it means is that even a sessionStorage item of link http://testerops.com , would be different and non-accessible for sessionStorage item of link https://testerops.com – because the http schema is different.

  • Data stored in sessionStorage object is per-instance. per-window or per-tab. In other words, the sessionStorage object’s lifespan expires once users close the instance (window or tab).

  • Browsers create a unique page session for each new tab or window. Therefore, users can run multiple instances of an app without interfering with each instance’s session storage. (Note: Cookies do not have good support for running multiple instances of the same app. Such an attempt can cause errors such as double entry of bookings.)

  • As in case of localStorage, sessionStorage is also a property of the global Window object. Therefore, sessionStorage.setItem() is equivalent to window.sessionStorage.setItem().

  • sessionStorage stores data in strings. If you need to store complex data types like objects or arrays, you will need to serialize them into strings using methods such as ‘JSON.stringify()’ before storing and ‘JSON.parse()’ when retrieving.

Let’s See In Action

Ok. So much of text. Let’s see some work in action. So to start with let’s open a new incognito browser instance of Chrome.

Right click and open Inspect and head over to the console tab – and then type this

sessionStorage.setItem("valueofone",4);

And then write this

alert( sessionStorage.getItem('valueofone') )

As soon as you type this and press Enter, you’ll see this value in the browser

Now open a new tab and then type the second statement in the console tab- which is for showing the alert

alert( sessionStorage.getItem('valueofone') )

Now , you will see null , because the new tab sessionStorage doesn’t has access to valueofone . So it outputs null.

Now repeat this by either closing the original tab or closing the Incognito window all together and then opening a new browser window and trying again. You’ll see null being returned in both cases since the sessionStorage data has now been destroyed.

In the next post, we will try to see what is Indexed DB, and what are it’s uses.