What Is a Web Storage Test?
This tool actually writes a real, uniquely-named piece of test data into both
localStorage and sessionStorage, reads it back, confirms the value matches exactly,
and then removes it - a genuine functional round-trip test rather than simply checking whether the storage
APIs exist. This distinction matters because some browsers or privacy settings can expose the storage APIs
while still throwing errors or silently failing when actually used, particularly in strict privacy modes or
certain embedded contexts.
How to Use the Web Storage Test
- Load this page - both tests run automatically.
- Check the result for each storage type: "Working (verified)" confirms a genuine successful round trip.
- Note the item count for each storage type, reflecting how many entries currently exist for this site.
- Click "Run Test Again" to repeat the check, for example after changing a privacy setting.
How It Works
For each storage type, this tool calls setItem() with a unique test key and value, then
immediately calls getItem() to read it back, and compares the returned value against what was
written. Only an exact match is reported as genuinely working. The test key is removed with
removeItem() immediately afterward, regardless of the outcome, so nothing persists beyond
confirming the result. If any step throws an exception - which some browsers do in strict privacy modes -
that's caught and reported as a failure with the specific error type shown.
Understanding Your Results
- Both show "Working (verified)" - your browser fully supports both storage types in its current context, which is the expected result for most standard browsing.
- localStorage fails but sessionStorage works, or vice versa - uncommon, but can happen in some specific privacy configurations or embedded browser contexts that treat the two differently.
- Both fail with a "SecurityError" or similar - often indicates storage is fully blocked in the current context, such as certain strict private browsing modes or when a page is loaded inside a restricted iframe.
- Item counts seem unexpectedly high - reflects genuine existing data other parts of this website, or previous visits, may have already stored for this domain.
Browser Limitations
Some browsers, particularly Safari in certain private browsing configurations, have historically exposed the storage APIs but thrown quota-related errors immediately upon any write attempt - a case this tool's functional test is specifically designed to catch, unlike a simple existence check that would incorrectly report support. Storage limits also vary by browser, though the small test value used here is far below any realistic browser storage limit and won't itself trigger a quota issue.
Common Mistakes to Avoid
- Assuming storage support based on the API simply existing - some restricted contexts expose the API object but fail on actual use, which only a functional test like this one reveals.
- Confusing localStorage and sessionStorage - localStorage persists across browser restarts, while sessionStorage clears when the tab or browser closes; both are tested here independently.
- Testing inside a restrictive iframe and expecting normal results - some embedded contexts intentionally restrict storage access as a security measure.
Frequently Asked Questions
What's the difference between localStorage and sessionStorage?
localStorage persists data even after you close and reopen your browser, while sessionStorage clears automatically when the current tab or browser session ends - both are tested independently here.
Why test this instead of just checking if the API exists?
Some browsers and privacy modes expose the storage API objects but throw errors on actual use; a real write-and-read test catches that gap that a simple existence check would miss entirely.
Is my test data sent to any server?
No, this test only reads and writes locally within your browser's storage - nothing is transmitted anywhere, and the test data is removed immediately after verification.
Why might my browser show a failure here?
Strict private browsing modes, certain embedded iframe contexts, or specific privacy extensions can block storage access even when the underlying API objects are technically present.
Does a failed test mean my browser is broken?
No, it usually reflects an intentional privacy restriction in your current browsing mode or context rather than a fault; many websites that rely on storage simply won't function as expected under those same restrictions.
Conclusion
A genuine write-and-read test gives you real confidence that storage actually works in your current browsing context, not just that the underlying API is technically present. For a similar functional check of cookies, see the Cookies Enabled Test.