Web Storage Test - Real localStorage & Session

What Is a Web Storage Test?

A Web Storage Test checks whether this particular browser page can actually use the localStorage and sessionStorage APIs. Merely detecting the APIs is insufficient: some browser settings, sandboxed documents or storage policies expose an API but prevent writes. This tool creates its own synthetic data, reads the exact values back and checks that deletion succeeds. It never clears or displays the website's existing storage entries.

How to Use the Web Storage Test

1. Open the page: the localStorage and sessionStorage tests start automatically. Each API is tested independently with a small Unicode value and an approximately 1,024-character synthetic value.
2. Read both storage cards: VERIFIED means both values were written, read back exactly and removed successfully. NOT VERIFIED identifies an unsuccessful storage operation; WARNING means a cleanup could not be confirmed.
3. Review the detailed checks: see which payload passed and whether deletion was confirmed. Item counts show the number of accessible keys remaining in each storage area, without revealing their names or contents.
4. Review operation times: the tool measures only the combined synchronous setItem/getItem/removeItem calls in this run. Very small times may be rounded by browser timer precision; these are not standardized disk or device benchmarks.
5. Optional quota estimate: click CHECK ESTIMATE to request read-only navigator.storage.estimate() numbers. These values are for overall browser-managed origin storage, not the exact available space in localStorage or sessionStorage.
6. Repeat and export: select RUN TEST AGAIN after adjusting privacy settings; use COPY SUMMARY or DOWNLOAD JSON for a diagnostic report. The report omits existing storage keys, their values and the temporary synthetic tokens.

How It Works

For each Web Storage API, the page allocates a new randomly named temporary key after checking that no value already exists under that name. It writes a synthetic string, reads it back with getItem(), compares it exactly and then calls removeItem(). The tool checks that getItem() returns null after removal, even if an earlier step fails. It repeats this sequence for two deliberately small test payloads and records observed operation times using a browser timer. It does not call clear(), perform destructive quota filling, or access unrelated stored values.

The optional navigator.storage.estimate() request is separate. Its reported origin-wide usage and quota may include IndexedDB, Cache API and other browser-managed data, and may exclude Web Storage. The estimate is approximate and is not evidence that either tested Web Storage area can store that many bytes. Neither test demonstrates that data will survive reloads, browser restarts or future storage eviction.

Understanding Your Results

• Both storage types verified: current-context small-payload writes, exact reads and cleanup succeeded for both APIs. This is not a promise of long-term persistence or third-party iframe support.
• Only one type verified: the other may be blocked, out of quota or unavailable in this document. Check its details rather than treating every storage API as disabled.
• Access denied / SecurityError: the browser may be applying a privacy, origin, sandbox or policy restriction. This does not by itself indicate broken hardware.
• QuotaExceededError: a write was rejected. The relevant storage area may be full or browser settings may prevent writes. The tool does not deliberately try to fill storage.
• Warning / removal not confirmed: a temporary key could not be verified as deleted. The page does not mark such a run as fully verified; use the browser's site-storage settings if you need to inspect or clear your own data.
• Operation time and item count: timing reflects only this small set of synchronous API calls; item count reports the current area's accessible entries, not total device storage or the contents of other websites.

Browser Limitations

Both Web Storage APIs are synchronous and can block JavaScript while large operations execute. This tool intentionally uses small payloads to minimize impact. In private browsing, storage may work temporarily but be discarded when the private session ends. localStorage is scoped by origin, while sessionStorage is additionally associated with the tab's page session. An embedded frame, an opaque-origin document or a strict privacy configuration may have different access rules.

Browser-reported storage estimates are approximate, may be privacy-rounded and do not represent a reliable quota for localStorage or sessionStorage. Storage can also be cleared by the user or browser. This tool does not test reload survival, cross-tab events or persistence across restarts, and does not request persistent-storage permission.

Common Mistakes to Avoid

• Assuming an exposed API always works: a real write/read/delete round trip is more informative than feature detection alone.
• Confusing origin-wide quota with Web Storage capacity: a successful navigator.storage.estimate() response is neither an exact localStorage limit nor proof that a large write would succeed.
• Interpreting a one-time pass as permanent storage: immediate readback does not prove data survives reload, restart, privacy cleanup or quota pressure.
• Clearing the site's existing keys to run a diagnostic: this tool never calls clear(). Manually clearing existing site storage could log you out or affect website settings.
• Comparing tiny timing differences as hardware scores: browser timer rounding, system load and synchronous execution can dominate short-operation measurements.

Frequently Asked Questions

Conclusion

Checking real temporary writes, reads and verified cleanup is a practical way to evaluate Web Storage support in the current browser context. The optional origin-wide quota estimate is informative but different from measuring localStorage or sessionStorage limits. For a related first-party check, use the Cookies Enabled Test.