v149 · Clipboard · Eager vs. Lazy

Eager vs. Lazy Comparison

Before Chrome 149, clipboard.read() fetched all format data immediately. After Chrome 149, read() returns only the type list — data is fetched lazily per format. This comparison shows the timeline difference and the code change required.

These timelines are illustrative based on a typical clipboard containing text/plain, text/html, and image/png. Actual times depend on clipboard content size and OS.

timeline comparison

Before Chrome 149 — eager

App needs only text/plain:

clipboard.read()
~80 ms
Fetches all: text/plain + text/html + image/png
getType('text/plain')
~2 ms
Returns already-fetched blob

Total before app gets text: ~82 ms

Chrome 149+ — lazy

App needs only text/plain:

clipboard.read()
~8 ms
Returns type list only — no data fetched
getType('text/plain')
~12 ms
Only text/plain read from OS

Total before app gets text: ~20 ms

Eager (all formats) Lazy fetch Already in memory

code change

// BEFORE Chrome 149 — identical code, but eager under the hood
const items = await navigator.clipboard.read();
// ^ All format data fetched here (slow for large clipboards)

for (const item of items) {
  const blob = await item.getType('text/plain');
  // ^ Just returns the already-loaded blob — fast, but wasted work above
}

// AFTER Chrome 149 — same code, lazy under the hood
const items = await navigator.clipboard.read();
// ^ Only type list fetched — fast even with large clipboard

for (const item of items) {
  // Only items that call getType() trigger an OS clipboard read:
  if (item.types.includes('text/plain')) {
    const blob = await item.getType('text/plain');
    // ^ Fetches only text/plain from the OS — skips image/png, text/html
  }
}

// No code change required — Chrome 149 makes this automatically lazy

what sites benefit most

see also

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗