use-local-storage: Failed to get value from storage, localSt

Error message

use-local-storage: Failed to get value from storage, localStorage is blocked

What it means

This is a console.warn (not a thrown error) emitted by use-local-storage (and use-local-storage-shared) when reading from window.localStorage throws. It means browser storage access is blocked, so the hook cannot retrieve the persisted value and returns null. The hook degrades gracefully and keeps working with in-memory state only.

Source

Thrown at packages/@mantine/hooks/src/use-local-storage/create-storage.ts:48

  } catch (error) {
    throw new Error(`@mantine/hooks ${hookName}: Failed to serialize the value`);
  }
}

function deserializeJSON(value: string | undefined) {
  try {
    return value && JSON.parse(value);
  } catch {
    return value;
  }
}

function createStorageHandler(type: StorageType) {
  const getItem = (key: string) => {
    try {
      return window[type].getItem(key);
    } catch (error) {
      console.warn('use-local-storage: Failed to get value from storage, localStorage is blocked');
      return null;
    }
  };

  const setItem = (key: string, value: string) => {
    try {
      window[type].setItem(key, value);
    } catch (error) {
      console.warn('use-local-storage: Failed to set value to storage, localStorage is blocked');
    }
  };

  const removeItem = (key: string) => {
    try {
      window[type].removeItem(key);
    } catch (error) {
      console.warn(
        'use-local-storage: Failed to remove value from storage, localStorage is blocked'

View on GitHub (pinned to 8a284e2c2c)

Solutions

Verify it is only a warning: the hook still works, values just won't persist — often safe to ignore in production
Reproduce the user's browser state: enable 'Block third-party cookies' in Chrome or use Safari private mode to confirm storage is blocked
If in an iframe, request storage access via Storage Access API (document.requestStorageAccess()) or serve the embed first-party
Provide a fallback storage (e.g. cookie-based or in-memory manager) when localStorage access throws

Example fix

// Detect blocked storage before relying on persistence
function storageAvailable() {
  try {
    const k = '__t';
    window.localStorage.setItem(k, '1');
    window.localStorage.removeItem(k);
    return true;
  } catch {
    return false;
  }
}
const value = useLocalStorage({ key: 'k', defaultValue: '' }); // still safe if blocked

Defensive patterns

Strategy: fallback

Validate before calling

function isLocalStorageReadable(): boolean {
  try {
    const k = '__probe__';
    window.localStorage.setItem(k, '1');
    window.localStorage.removeItem(k);
    return true;
  } catch {
    return false;
  }
}

Type guard

const isLocalStorageAvailable = (): boolean => {
  try {
    return typeof window !== 'undefined' && window.localStorage !== null;
  } catch {
    return false;
  }
};

Try / catch

// Library already catches internally; only warn suppression is relevant.
// To silence in tests:
const warnSpy = vi.spyOn(console, 'warn').mockImplementation(() => {});

Prevention

Treat use-local-storage as best-effort persistence; design features to work without stored values
Mock localStorage fully (getItem/setItem/removeItem) in Jest/Vitest setups
For iframes, request storage access before loading the app
Watch for these warnings in QA on Safari private mode and cookie-blocked Chrome

When it happens

Trigger: window.localStorage.getItem(key) throws — typically when cookies/site data are blocked (Chrome 'Block third-party cookies' + iframe/embed contexts), Safari ITP private mode, browser privacy settings, or SSR environments where localStorage is unavailable. Emitted on mount and on any read triggered by the 'storage' event handler.

Common situations: App embedded in an iframe (widgets, embedded dashboards) with third-party cookies blocked; Safari private browsing; users with strict privacy extensions or 'block all cookies' enabled; corporate browser policies; headless test environments mocking window without localStorage.

Related errors

AI-assisted analysis of mantinedev/mantine@8a284e2c2c (2026-08-28). Data as JSON: /api/errors/09a32d0269314160. Report an issue: GitHub.