What are localStorage's capacity and synchronous blocking limitations?

What's really being asked

The interviewer wants to know if you understand why localStorage is unsuitable for performance-critical or data-heavy web applications. They are looking for awareness of main-thread blocking, storage quotas, and the ability to name better alternatives. This separates developers who treat browser APIs as black boxes from those who consider UX and thread behavior.

The full answer

First, synchronous blocking: every setItem, getItem, and removeItem call on localStorage executes synchronously on the main thread, meaning the event loop cannot process rendering or input events until the operation completes. Second, capacity limits: localStorage offers a finite per-origin quota, and attempting to exceed it throws a QuotaExceededError; data may also be evicted under storage pressure. Third, data model constraints: it stores only strings, so objects require serialization, and it provides no indexing, querying, or transactional support. Fourth, impact on UX: blocking the main thread can cause dropped frames, delayed button clicks, and janky scrolling, especially on low-end devices or when storing large serialized strings. Fifth, alternatives: mention IndexedDB for asynchronous, structured, larger-scale storage, or the Cache API for request-response pairs.

The mistakes people make

A red flag is suggesting that wrapping localStorage in a Promise or async function makes it non-blocking; the underlying API remains synchronous, so the main thread still pauses. Another mistake is claiming there is no storage limit or quoting an exact universal megabyte number without noting that quotas vary by browser and user settings. Saying localStorage is acceptable for caching large API responses or binary data also signals a lack of judgment, since serialization overhead and quota limits make this dangerous.

What usually comes next

The interviewer may ask how you would migrate localStorage data to IndexedDB without dropping frames, which involves batching writes inside a requestIdleCallback or breaking work into smaller chunks with setTimeout. They might also ask how third-party iframe access is restricted, or how the Storage Event can be used to synchronize tabs. Another follow-up is comparing sessionStorage to localStorage in terms of lifespan and tab scoping.

A concrete example

Imagine a productivity app that saves a large JSON workspace to localStorage on every keystroke. Because localStorage setItem is synchronous, each save blocks the main thread for several milliseconds; at fifty keystrokes per minute, the UI becomes sluggish and the frame rate drops. The correct fix is to debounce the saves and move the data to IndexedDB, where write operations happen off the main thread and the app remains responsive even with multi-megabyte documents.