Re: [whatwg/storage] Maximum file size that storage should support (Issue #181)

elkurin left a comment (whatwg/storage#181)

Hi all,

To move the discussion on this issue forward, I'd like to make a concrete proposal.

**Option A: 4GB**

*   **Pros:**
    *   It's likely that many implementations have bugs around `int32_t` limits. A 4GB limit would help identify and fix these bugs.
*   **Cons:**
    *   As I pointed out, with use cases already exceeding 2GB, a 4GB limit might not be sufficient for future needs like caching LLM models.

**Option B: 100GB**

*   **Pros:**
    *   This would be more future-proof and accommodate use cases like LLMs.
    *   This is technically feasible, as Chromium's implementation already has a mechanism to support this size.
*   **Cons:**
    *   As @annevk mentioned, this could lead to the user agent clearing temporary storage more quickly, potentially nullifying the benefit of caching.

**A Note on Testing**
As @asutherland pointed out, running WPTs with very large files is impractical.
One solution could be to mandate support for large files (e.g., 4GB + 1 byte) in the specification, while using a smaller, test-only quota in WPTs to efficiently test the logic around the limit.

**Questions for the group:**
1.  Between options A and B, which do you find more reasonable?
2.  Are there other limits or approaches we should consider?
3.  Is the proposed approach to testing acceptable?

Personally, I am in favor of Option B. I agree with @fergald's point from the original thread. Developers are already storing large files, but in non-ergonomic ways like breaking them into chunks in IndexedDB. Given that this is a legitimate and common use case, we should make it ergonomic. Formal support in CacheStorage would improve the situation.

I look forward to hearing your thoughts.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/storage/issues/181#issuecomment-3600216136
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/storage/issues/181/3600216136@github.com>

Received on Tuesday, 2 December 2025 05:09:40 UTC