Skip to calculator
Veomark

Free · Instant · No signup

This-Origin Web Storage Inspector

Inspect storage this page can access. It is not a cross-origin or bookmarklet debugger.

Page updated 2026-09-04.

This-Origin Web Storage Inspector visual
Sponsored

Calculator

Calculated Results

Key count

--

Sponsored

Why this tool needs a live browser context to work at all

Checking localStorage in this context returns 'Storage is not available in this context' -- not a bug, but the expected result when the Web Storage API is queried outside a normal, live browser page context (such as during server-side rendering or a sandboxed evaluation), since localStorage and sessionStorage are browser APIs tied to an actual page origin.

In a real browser tab visiting an actual website, this same check would return the count and names of keys currently stored in that origin's localStorage (or sessionStorage, depending on which is selected) -- the tool works as intended once run in its actual intended environment.

Web Storage is strictly scoped per origin (protocol + domain + port) -- a key stored by one site is never visible to a different site's storage inspection, by browser design, which is a foundational security boundary of the Web Storage API.

What this inspector deliberately doesn't show

Reads this origin only. Values are not printed so secrets stay off the page. This tool shows key names and a count, but deliberately doesn't print the actual stored values -- many sites store session tokens, auth state, or other sensitive data in localStorage, and displaying those values on screen (or in a screenshot, or accidentally shared) would be a real information-exposure risk this design choice avoids.

It only reads the current page's own origin storage -- it has no ability to inspect another site's localStorage, both because browsers don't allow cross-origin access to storage and because this tool doesn't attempt to work around that boundary.

localStorage persists until explicitly cleared (by the site, the user, or a browser storage-clearing action), while sessionStorage clears when the browser tab closes -- selecting the wrong storage type for what you're investigating could show an empty or unexpected result even on a site actively using the other type.

Using this for real debugging

To actually inspect a site's storage, open this tool (or your browser's own DevTools Application/Storage panel) while visiting that site directly, rather than through an embedded or sandboxed context where storage access is restricted.

For inspecting cookies specifically, which follow different scoping and expiration rules than localStorage, the Cookie String Parser is the related tool.

Frequently Asked Questions (FAQ)

Why does this show 'Storage is not available in this context'?

The Web Storage API (localStorage/sessionStorage) requires a live browser page context tied to a real origin. When queried outside that normal context, the API isn't accessible, so the tool correctly reports it as unavailable rather than returning misleading data.

Does this tool show the actual values stored, or just key names?

Reads this origin only. Values are not printed so secrets stay off the page. Only key names and a count are shown, deliberately. Many sites store sensitive data (session tokens, auth state) in localStorage, and this design choice avoids displaying that sensitive content on screen.

Can this inspect another website's localStorage?

No. Reads this origin only. Values are not printed so secrets stay off the page. Web Storage is strictly scoped per origin by browser design -- one site's storage is never accessible to another site's page, and this tool works within, not around, that boundary.

What's the difference between checking localStorage and sessionStorage here?

localStorage persists until explicitly cleared; sessionStorage clears automatically when the browser tab closes. Selecting the wrong one for what you're investigating could show an empty result even on a page actively using the other storage type.

How would I actually use this tool to debug a real site's storage?

Run it directly on a page visiting that site (not embedded in a restricted or sandboxed context), similar to how you'd use a browser's own DevTools Application/Storage panel to inspect the current page's actual storage state.