How Safari Expanded Origin Storage and Cache Quotas

This article explains how updates to the storage quota architecture in the Safari web browser drastically increased the disk space available for web applications. By replacing restrictive static limits with a dynamic, unified quota system based on total device storage, Safari now allows individual origins and their Service Worker caches to utilize significantly more disk space. These changes enable reliable offline web applications, large media caching, and complex browser-based software across macOS and iOS.

The Shift to a Unified Storage Architecture

Historically, Safari managed different web storage APIs—such as IndexedDB, LocalStorage, and the Cache API used by Service Workers—through separate mechanisms with strict, fragmented size limits. When a web app exceeded its initial tiny allocation (often just 50MB), Safari either blocked further writes or interrupted the user with prompts asking for permission to use more space.

To solve this, WebKit engineers completely rewrote Safari’s storage backend to use a unified origin storage architecture. Under this model, almost all modern storage APIs are managed together in a single directory per origin. This includes:

  • Service Worker Caches (Cache API)
  • IndexedDB
  • Origin Private File System (OPFS)
  • Web Locks and Broadcast Channels metadata

Because these APIs now share a single underlying management system, Safari no longer enforces arbitrary, isolated micro-limits on Service Worker caches. Instead, the Cache API draws from the exact same expansive pool of disk space as the rest of the origin's data.

Dynamic Quotas Based on Total Disk Space

The biggest expansion in available space comes from how Safari calculates storage limits. Rather than relying on hardcoded megabyte caps or calculating limits strictly from free disk space—which fluctuates wildly and makes quota management unpredictable—Safari now calculates quotas based on the device's total disk capacity.

The updated architecture allocates space using the following rules:

  • Per-Origin Quota: A single top-level origin (website) is allowed to use up to 60% of the total disk space on the device.
  • Overall Browser Quota: Across all websites combined, Safari allows web storage to consume up to 80% of the total disk space.
  • Third-Party Iframes: To prevent embedded trackers or cross-site scripts from exhausting a device's storage, third-party iframes are partitioned and restricted to a quota that is one-tenth the size of the first-party origin quota.

For example, on a device with a 256GB hard drive, a single web application and its Service Worker can theoretically store over 150GB of data in the browser, provided the space is not already taken by the operating system or other native apps.

Impact on Service Worker Caches

Service Workers rely heavily on the Cache API to store network responses, application shells, and large static assets for offline use. Under the old architecture, caching high-resolution images, audio files, or WebAssembly binaries for games would rapidly trigger a QuotaExceededError.

With the unified architecture and the 60% total disk limit:

  1. Large Asset Caching: Service Workers can precache gigabytes of assets in the background without hitting artificial ceilings.
  2. No User Prompts: The browser allocates this space silently. Users are never interrupted with dialog boxes asking if a website can store more data.
  3. Predictable Estimation: Developers can use the navigator.storage.estimate() API to programmatically check how much space their Service Worker cache is using and how much total quota remains.

Automated Eviction and Persistent Storage

Allowing single origins to consume up to 60% of a disk requires a strict cleanup mechanism so the user's device does not run out of actual free space. Safari handles this by pairing expanded quotas with an automated eviction algorithm.

By default, all origin storage and Service Worker caches are classified as "best-effort." If the total storage used by all origins breaches the 80% overall limit, or if the host operating system reports critically low disk space, Safari triggers a Least Recently Used (LRU) eviction policy.

Crucially, Safari evicts data at the origin level, not the individual API level. It will delete all data (IndexedDB and Service Worker caches together) for the least recently visited website rather than purging just the Service Worker cache of an active app, which prevents web applications from entering broken, half-cached states.

To protect critical data from this automatic purge, Safari also implemented support for the Storage Standard's persistence API. Web apps can call navigator.storage.persist() to request that their origin be exempt from automatic LRU eviction. Safari grants this request based on heuristics, such as whether the user has installed the web app to their Home Screen or Dock, ensuring that essential offline apps retain their massive storage allocations permanently.