sessionStorage: Tab-Specific Browser Memory
sessionStorage is temporary browser memory isolated to a single tab. Use it to save state within a single user workflow, like form data. The footgun: unlike localStorage, this data is *not* shared between tabs, even for the same site.
Why it exists
Web apps often need to remember small amounts of data temporarily without using a server or permanent client-side storage. sessionStorage was created to hold data for a single "session," which is defined as the life of one browser tab.
The mental model
Think of sessionStorage as a temporary scratchpad for a single browser tab. Each tab gets its own separate scratchpad. You can write on it, read from it, and it persists if you refresh the page. But as soon as you close the tab, the scratchpad is wiped clean.
How it works
sessionStorage is a Web API that provides a Storage object for the current origin, scoped to the current tab. It stores data as key-value pairs, where both keys and values are always strings. You can add data with sessionStorage.setItem('myKey', 'myValue'), retrieve it with getItem('myKey'), and remove it with removeItem('myKey') or clear(). The storage is tied to the page session, which lasts only as long as the tab is open.
When to use it
Use it for short-lived data relevant only to the current user task. A great use case is saving form data as a user navigates a multi-step process within one tab. If they refresh, the data is restored, but it doesn't pollute their browser storage forever or get shared with other tabs.
When not to use it
Do not use sessionStorage for data that needs to persist between sessions or be shared across tabs; use localStorage for that. Avoid it for sensitive information like authentication tokens, as it's accessible via JavaScript and thus vulnerable to XSS attacks. It is also limited in size, typically around 5-10MB.
One canonical example
A common pattern is auto-saving user input in a large text field. You can use an event listener to save the field's content to sessionStorage with sessionStorage.setItem('autosave', field.value). When the page loads, you check if sessionStorage.getItem('autosave') exists. If it does, you restore the value to the text field, preventing data loss on an accidental refresh.
Interview question
When a user opens a new tab to the same website, what happens to the sessionStorage data from the original tab?
- a.A new, independent sessionStorage is created for the new tab.Correct
- b.The data is shared and accessible in both tabs.
- c.The data is deleted from the original tab and moved to the new one.
- d.The data persists in the original tab but is read-only in the new tab.
Why? this is the answer
sessionStorage is explicitly isolated to a single tab, meaning each tab gets its own separate instance. Therefore, opening a new tab creates a completely new, independent sessionStorage, not sharing data with existing tabs. Option B is incorrect because sessionStorage is not shared between tabs, which is a common misconception.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #web apis
- #browser storage
- #javascript
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on web apis — each one lists the topics its interview covers.
See open roles