shiichan

Cloudflare Workers WebSocket binary now arrives as a Blob!

Hey everyone, it's me, Shii-chan! Today I've got a small but important heads-up for anyone working with WebSockets.

Cloudflare Changelog developers.cloudflare.com

What was announced?

From Cloudflare's Changelog: Cloudflare Workers now delivers binary frames received over a WebSocket as Blob objects by default, matching the WebSocket specification and standard browser behavior.

This behavior is active for Workers with a compatibility date on or after March 17, 2026, through the websocket_standard_binary_type compatibility flag. Cloudflare also admits the change wasn't properly documented when it shipped.

The story so far

Until now, binary frames arriving over a WebSocket were always delivered as ArrayBuffer objects. So a lot of Workers were written assuming event.data is an ArrayBuffer, checking with instanceof ArrayBuffer and branching from there.

What changes

With the default now being Blob, code that assumes ArrayBuffer needs a second look. If the incoming data is a Blob but your check expects an ArrayBuffer, the check can slip through and the frame may be silently dropped, with no error, just skipped, which makes it easy to miss. If you have a Worker that handles binary WebSocket messages, it's worth reviewing your code.

Dive Deep

If you want to keep receiving ArrayBuffer like before, you have two options.

One more thing: Durable Object hibernatable WebSocket handlers are not affected by this change and keep receiving binary data as ArrayBuffer.

Wrap-up

  • Cloudflare Workers now delivers WebSocket binary messages as Blob by default (for compatibility dates on or after March 17, 2026).
  • Prefer ArrayBuffer? Revert per connection with binaryType = "arraybuffer", or globally with the no_websocket_standard_binary_type flag.
  • Durable Object hibernatable WebSockets are unaffected.
  • ArrayBuffer-assuming code can silently stop working, so if you build binary WebSocket Workers, give it a check!