What Are the Size Limits of Web Storage Mechanisms?
Learn the real size limits of cookies, localStorage, and IndexedDB, why they differ, and how to avoid QuotaExceededError.
Expected Interview Answer
Cookies are limited to roughly 4KB per cookie (and a per-domain count cap around 50-180 depending on the browser), localStorage and sessionStorage typically cap out around 5-10MB per origin, and IndexedDB can grow to a large percentage of available disk space, often hundreds of megabytes to gigabytes, subject to browser-specific quota and eviction rules.
These limits exist because each mechanism was designed for a different job: cookies were built for tiny identifiers that ride along with HTTP headers, so a large cookie inflates every request; localStorage was designed for simple, synchronous client preferences, so browsers cap it low enough to keep it fast; IndexedDB was designed as a real client-side database for offline apps, so its quota scales with available disk space rather than a fixed small number. Browsers enforce these caps differently — Chrome and Firefox compute IndexedDB quota as a percentage of free disk space per origin group, while Safari has historically been stricter and may evict data under storage pressure unless the origin is granted persistent storage via the Storage API. When a write exceeds a quota, localStorage and sessionStorage throw a QuotaExceededError synchronously, while IndexedDB transactions fail asynchronously with a quota error event. In practice, exceeding these limits is a sign the wrong storage mechanism was chosen — cookies for large payloads or localStorage for large datasets are both red flags in a code review.
- Small cookie limits keep every HTTP request lightweight
- localStorage caps keep synchronous access fast enough not to block rendering
- IndexedDB quotas scale with disk space, supporting real offline-first applications
- Understanding limits upfront avoids runtime QuotaExceededError surprises
AI Mentor Explanation
A cookie is like the tiny entry stub a fan must carry through every gate — it has to stay small enough that security can check it instantly at each checkpoint without slowing the queue. localStorage is like the small locker each fan gets at the ground, useful for a jacket and a scorecard but never big enough for a full kit bag. IndexedDB is like the stadium's equipment warehouse, sized against the actual available storage space in the building, capable of holding entire team inventories as long as the warehouse has room. Each limit reflects the different job each storage space was built to do.
Step-by-Step Explanation
Step 1
Check cookie size before setting
Keep cookies well under 4KB and avoid storing anything beyond identifiers or small tokens.
Step 2
Budget localStorage usage
Treat the ~5-10MB origin cap as a hard ceiling for small preference or cache data only.
Step 3
Request persistent storage for IndexedDB
Use navigator.storage.persist() so the browser is less likely to evict IndexedDB data under pressure.
Step 4
Handle quota errors gracefully
Catch QuotaExceededError on localStorage writes and quota-related events on IndexedDB transactions.
What Interviewer Expects
- Approximate size figures for cookies, localStorage, and IndexedDB
- Understanding that limits vary by browser and are not a fixed spec guarantee
- Awareness of QuotaExceededError and how each mechanism signals overflow
- Knowledge that IndexedDB quota scales with disk space rather than being fixed
Common Mistakes
- Assuming all browsers enforce identical byte-for-byte storage limits
- Not handling QuotaExceededError when writing large amounts of data
- Storing large binary blobs in localStorage instead of IndexedDB
- Forgetting that Safari can be more aggressive about evicting unpersisted storage
Best Answer (HR Friendly)
“Cookies are meant to be tiny, only a few kilobytes, because they get sent with every request. localStorage is a bit bigger, usually around 5 to 10 megabytes, good for small settings. IndexedDB is the biggest, scaling with how much free space is on the device, so it is the right choice for large amounts of data like offline content.”
Code Example
// Estimate available storage (mostly reflects IndexedDB headroom)
async function checkQuota() {
if (navigator.storage && navigator.storage.estimate) {
const { usage, quota } = await navigator.storage.estimate()
console.log(`Using ${usage} of ${quota} bytes`)
}
}
// localStorage throws synchronously when the origin cap is exceeded
function safeSetItem(key, value) {
try {
localStorage.setItem(key, value)
} catch (err) {
if (err.name === 'QuotaExceededError') {
console.warn('localStorage full, falling back to IndexedDB')
}
}
}Follow-up Questions
- How does navigator.storage.persist() affect IndexedDB eviction behavior?
- Why might Safari evict site data more aggressively than Chrome?
- How would you detect and handle a QuotaExceededError on localStorage?
- What strategy would you use to migrate data from localStorage to IndexedDB once approaching quota?
MCQ Practice
1. Roughly how large is the typical per-origin localStorage limit?
Most browsers cap localStorage at roughly 5-10MB per origin.
2. What determines the practical size limit of IndexedDB?
IndexedDB quota generally scales with free disk space rather than a small fixed number.
3. What error is thrown when a localStorage write exceeds its quota?
Browsers throw a QuotaExceededError synchronously when the storage cap is hit.
Flash Cards
Typical cookie size cap? — About 4KB per cookie.
Typical localStorage cap? — Roughly 5-10MB per origin.
What governs IndexedDB's limit? — A quota that scales with available disk space.
What API helps prevent IndexedDB eviction? — navigator.storage.persist().