What this usually means
If your Pinia store state vanishes after a reload, it usually means your state persistence plugin isn’t registering, storage isn’t configured, or your hydration logic in SSR/Nuxt stacks is resetting state from the server rather than localStorage. Sometimes, a mismatch in store initialization, incorrect use of the persist plugin, or browser storage restrictions block the expected behavior. This is rarely a bug in Pinia itself—instead, it’s almost always a miswiring in storage plugin registration, SSR/client hydration order, or use of multi-tab strategies.
The first ten minutes — establish facts before touching code.
- 1Open Application tab in Chrome DevTools and check the localStorage/IndexedDB for expected Pinia keys after a mutation.
- 2In main.ts, verify you actually imported and registered pinia-plugin-persistedstate via `pinia.use(createPersistedState())` before mounting the app.
- 3Check your store definition: does it include `persist: true` or relevant plugin options?
- 4Refresh and watch for pinia keys being set/cleared in localStorage; use `window.localStorage.getItem('pinia')` in console.
- 5If using Nuxt or SSR, set breakpoints in the hydration lifecycle to see if client-side state loads from storage or server.
- 6Temporarily disable all other plugins/middleware to rule out interference.
The specific files, logs, configs, and dashboards that usually own this bug.
- searchsrc/main.ts (Pinia and plugin registration code)
- searchstore/*.ts (store definitions, plugin options, persist config)
- searchpackage.json (pinia-plugin-persistedstate or similar dependency versions)
- searchApplication tab > localStorage (`pinia` or custom keys)
- searchnuxt.config.js if using Nuxt (check `ssr` and plugin order)
- searchBrowser console for warnings/errors during store initialization
- searchNetwork tab for double-loads or failed fetches at reload
Practical causes, not theory. These are the things you will actually find.
- warningForgot to register the persistence plugin with Pinia in main.ts
- warningIncorrectly set or missing `persist: true` in store definition
- warningMultiple Pinia instances due to improper import paths
- warningServer-side state clobbering client state in SSR or Nuxt
- warningBrowser storage quota exceeded, preventing writes
- warningPersistence plugin version mismatch with Pinia runtime
- warningManual state resets in a router or layout lifecycle hook
Concrete fix directions. Pick the one that matches your root cause.
- buildExplicitly register the persistence plugin before mounting the Vue app
- buildAdd `persist: true` or detailed config in each Pinia store that needs persistence
- buildScope persisted state under unique keys to avoid collisions (especially in multi-store apps)
- buildIn SSR/Nuxt, ensure hydration logic merges local state instead of overwriting unconditionally
- buildUpgrade pinia-plugin-persistedstate (or alternative) to latest compatible version
- buildGuard against browser storage exceptions and log errors to surface storage failures
A fix you cannot prove is a guess. Close the loop.
- verifiedUpdate store state, reload page, and confirm state persists in UI and via Vue devtools
- verifiedCheck that localStorage keys contain the updated (not default) store values after reload
- verifiedRemove `persist` config, reload, confirm state resets as expected to verify plugin effectiveness
- verifiedSimulate SSR hydration: reload from different routes and confirm state isn’t lost
- verifiedTest in incognito/private window—verify if storage restrictions apply
- verifiedCheck consistent state across tabs if using multi-tab sync
Things that make this bug worse or harder to find.
- warningRegistering the persistence plugin after app mounting (it does nothing at that point)
- warningSetting `persist: true` in the wrong object level or on a non-Pinia store
- warningConfusing Vuex persistence plugins with Pinia plugins—they’re not compatible
- warningAssuming SSR will hydrate client state from localStorage automatically
- warningManually wiping state after plugin has restored it
- warningIgnoring browser storage quota errors (watch the console for DOMException)
Pinia State Lost After Refresh in Nuxt 3 App
Timeline
- 10:02User reports login state lost after every page reload
- 10:04Checked localStorage: no pinia keys written after login
- 10:06Reviewed store definition; found `persist: true` present
- 10:08Inspected nuxt.config.js; persistence plugin not listed in plugins
- 10:09Console log showed plugin not registered with Pinia instance
- 10:12Added `pinia.use(createPersistedState())` before app mount
- 10:13Reloaded, saw state persisted, login now survives refresh
A core user complained our Nuxt 3 app logged them out after every refresh. I first confirmed the default state was being reloaded by watching the devtools, and localStorage had no sign of persisted data.
Digging into our main entrypoint, I realized the pinia-plugin-persistedstate wasn't actually registered with the Pinia instance—despite being installed in package.json and present in the codebase. In Nuxt, our plugin file wasn't auto-registered because of a typo in the file extension.
Once I correctly registered the plugin before mounting the app, state began persisting in localStorage as expected. This highlighted the importance of verifying plugin registration order, especially in hybrid SSR setups.
Root cause
pinia-plugin-persistedstate was not registered with the Pinia instance before mounting, due to a plugin import oversight.
The fix
Explicitly called `pinia.use(createPersistedState())` before app.mount() in Nuxt entrypoint.
The lesson
Verify plugin registration order, and always check storage after initial state change—not just plugin presence in the codebase.
When using SSR frameworks like Nuxt 3, hydration order is critical. If you hydrate the client app using server-sent state, and persist plugins don’t run before the first render, the page may load the default or server state and overwrite localStorage, tossing user changes.
In these cases, check the nuxt.config.js for proper plugin inclusion and use `onBeforeMount` in your main App.vue to delay store access until persistence kicks in. Watch for double imports of Pinia (via different paths) causing multiple instances, which breaks persisted state restoration.
Browsers silently fail localStorage writes if the quota is exceeded or in privacy modes. Use a try/catch block in your persistence plugin config just to log storage errors.
Run this in the console: `try { localStorage.setItem('test', '1'); } catch(e) { console.error(e); }` to check for DOMException. Don't assume plugin success just because the dependency is present—verify actual key creation.
Pinia plugins must be registered with your Pinia instance before any component mounts. In src/main.ts, this order is non-negotiable: import Pinia, create instance, register plugin, then mount app.
Example: `const pinia = createPinia(); pinia.use(createPersistedState()); app.use(pinia).mount('#app');` — missing this order is the top real-world mistake.
Frequently asked questions
Why does my store lose state only in production, not development?
In production, minification or differing SSR hydration may change plugin execution order or cause stricter storage policies. Always check the build output and verify plugin order isn't disrupted by auto-imports or chunk splitting.
Is there a way to persist only part of my store?
Yes. In pinia-plugin-persistedstate, set the `paths` option in your store definition: `persist: { paths: ['user.token'] }` to persist only specific fields.
How can I debug if multiple tabs keep overwriting each other's state?
Pinia by default does not sync across tabs. Use the `storageEvent` in window to listen for changes, or a plugin supporting multi-tab sync. Otherwise, expect the last write to win.
Does removing `persist: true` clean up localStorage?
No. Removing persistence just stops future writes; old data stays. Clean up manually with `localStorage.removeItem('pinia')` or equivalent.