QuotaExceededError thrown inconsistently across browsers when localStorage quota exceeded

Synchronous Exception Behavior

In all mainstream modern browsers (Chrome, Firefox, Safari, and Edge), localStorage.setItem() throws a QuotaExceededError synchronously before any data is written to the disk. If the payload would exceed the origin's allocated quota, the operation fails immediately, and the storage state remains unchanged; no partial write occurs.

Exception Consistency and Type

The exception is consistently thrown as a DOMException. To reliably catch this across different user agents, you should verify the name property of the error object rather than the error message, as messages are localized and vary by browser.

try {
  localStorage.setItem('key', largeData);
} catch (e) {
  if (e.name === 'QuotaExceededError') {
    // Handle quota exhaustion
  }
}

Private Browsing and Quota Variations

Private or Incognito modes do not change the type of error thrown, but they significantly alter the threshold at which it occurs. While standard contexts typically allow 5MB to 10MB, private contexts may enforce much stricter limits or use ephemeral storage that triggers the exception sooner. Because the exact limit is implementation-defined, you cannot predict the failure point based on a fixed byte count.

Verification Steps

To verify the quota and exception behavior in your specific environment, use the following scoped approach in the browser console:

1. Test for Atomicity: Attempt to write a string larger than 10MB. Verify that the catch block triggers and that localStorage.getItem('testKey') returns null, confirming no partial write occurred.
2. Measure Threshold: Run a loop adding 1MB chunks to a key until the exception is thrown. Note the total bytes written to determine the current browser's limit.
3. Compare Contexts: Repeat the measurement in a Private/Incognito window to identify the delta in available space.

Diagnostic Note: Are you targeting legacy browsers (e.g., Internet Explorer) or specific mobile web-views? These may exhibit non-standard "best-effort" writes or different exception names that would require a broader catch strategy.