LocalStorage QuotaExceededError behavior across browser engines

Direct answer

The Web Storage specification does not define a 5 MB quota, nor does it specify whether the limit is measured in JavaScript characters or UTF-16 code units. It only requires that setItem() throw a QuotaExceededError DOMException when the key/value pair cannot be stored. In practice, engines account for the serialized key and value bytes plus internal storage overhead, so neither string.length nor UTF-16 byte length is a reliable quota unit.

For multiple writes, the behavior is consistent at the contract level but not at the threshold level: each setItem() is independent. The call that crosses the cumulative origin limit throws; earlier successful writes remain. There is no cross-setItem transaction, so many small records can exhaust the quota sooner than one large write because per-record overhead is repeated.

Confirmed contract vs. likely implementation detail

Confirmed by the specification:

• localStorage is synchronous and scoped per origin.
• Each setItem() is an independent operation.
• When storage is exhausted, the failing call throws a DOMException whose name is 'QuotaExceededError'.

Likely implementation detail (verify in your target runtime):

• Engines count serialized bytes plus overhead, not JavaScript string length.
• Exact byte cutoffs, overhead, and total quota vary by engine, version, platform, private/incognito mode, and storage partitioning.
• Repeated small records can fail earlier than a single large record of the same total payload because each record carries its own overhead.

What to do for strict budget management

1. Do not hard-code 5,000,000 characters or 5,242,880 UTF-16 bytes as safe. The quota is implementation-defined and may include overhead.
2. Pre-verify writes with a conservative estimate: use max(utf8Bytes(key+value), utf16Bytes(key+value)) plus a safety margin. There is no standard API that reports remaining localStorage bytes.
3. Catch by exception name, not numeric code: if (e.name === 'QuotaExceededError'). After a throw, verify the failing key was not persisted.
4. If an operation must be all-or-nothing across multiple keys, implement explicit rollback: catch the error and removeItem() the earlier keys you wrote in that logical operation.
5. Treat navigator.storage.estimate() only as an origin-wide signal. Its quota may include IndexedDB and Cache API usage and is not a localStorage-specific limit.

Practical verification

Because exact thresholds are implementation-defined, verify in the exact browser engine and profile you support:

• Clear localStorage, then binary-search the largest single value accepted before QuotaExceededError. Record the exception name and compare the accepted length against UTF-8 and UTF-16 byte counts.
• Repeat with many small unique-key writes until failure. Record how many succeeded and confirm earlier keys remain after the throw.
• Test with your real character mix (ASCII, Latin-1, CJK, emoji/surrogate pairs), because encoding changes byte length.
• Optionally compare navigator.storage.estimate() before and after the same writes, but treat the setItem failure point as authoritative.

One diagnostic detail that changes the recommendation

Which browser engine and version are you targeting? Quota behavior varies across engines, and private/incognito, mobile WebView, or low-storage conditions can lower or make quotas ephemeral. If you share the target runtime, the pre-check margin and rollback strategy can be tightened.