Inspect before you change

Storage bugs are much easier when you can see the state. Before writing more code, open DevTools and look at what’s already there.

Most “the setting didn’t save” reports turn out the same way. The value did save. It saved under a different key, in a different origin, or in a shape the new code no longer reads.

Where to look

In Chrome, Edge, and Safari the panel is called Application. In Firefox it’s Storage. Either way you get a tree with:

• Cookies, grouped by domain
• Local Storage and Session Storage, grouped by origin
• IndexedDB, with every database, object store, and index
• Cache Storage, with every named cache and the requests inside it
• Service Workers, if the origin registered one

Click a Local Storage entry and you can edit the value in place. Right-click an IndexedDB store and you can clear it. These are your fastest experiments. Change a value, reload, see what the app does.

Cookies are the exception. The response header that creates them is invisible to page JavaScript, so use the Network panel. Select a request and look for Set-Cookie in the response headers, then look at the next request for the Cookie header it produced.

Test on a clean origin

Your everyday browser profile is full of history. It may hold an IndexedDB database at version 3 from last month, a cache named help-v1 the current code never opens, or a cookie set by a script you deleted in March.

New code that works on a clean profile and breaks on yours is a real bug. It’s the bug your existing users will hit. Test both.

A private window gives you a clean slate quickly. It’s not a substitute for the real browser matrix, though. Safari and Firefox partition and evict differently from Chrome.

Be careful with what you share

A storage screenshot or a HAR export from the Network panel is a snapshot of real state. That includes session cookies, tokens, personal notes, and full response bodies.

Never paste one into a bug tracker, a chat, or an AI assistant without reviewing it first. Redact anything that looks like a credential. Better, reproduce the problem with test data and share that.

Audit a site you control

Open one real site you own and list every stored item you find. For each one, write down its apparent owner, then test whether it survives a reload, a new tab, a browser restart, and “clear site data”.

You’ll almost certainly find something you don’t recognize. That orphan is the first thing to clean up.