Web Push from Cloudflare Workers, Tested in Chrome and Edge

case                                  Chrome 155 (FCM)    Edge 155 (WNS)
payload, sent by the Worker handler   201, delivered      201, delivered
no payload                            201, delivered      201, delivered
payload, Urgency: high, a Topic       201, delivered      201, delivered
JWT aud set to another origin         403                 401
JWT expired an hour ago               403                 401
signed with another VAPID key         403                 401
4,200-byte body                       400                 201, Edge dropped it
old "WebPush <jwt>" header            201, delivered      201, delivered
TTL 0, browser closed                 201, never arrived  400
TTL 0, browser open                   not sent            400
TTL 1, browser open                   not sent            201, delivered
TTL 600, browser closed               201, on restart     201, on restart
unsubscribed, 4 s later               201                 201
unsubscribed, 2 min later             410                 201
unsubscribed, 15 min later            not sent            201
made-up endpoint token                410                 404

Why Not the web-push Package?

In Node the usual answer is the web-push package (version 3.6.7, 10.8 million npm downloads in the week to 2026-10-11). It encrypts through http_ece with crypto.createECDH, signs with jws and asn1.js, and sends with https.request. Several guides, including the most thorough one I found, say that is why it cannot run on Workers.

That claim is out of date. Cloudflare's own push notifications guide (updated 2026-10-12) imports web-push in a Worker with the nodejs_compat flag. The node:crypto page lists only DSA and DH key generation, argon2, ed448 and x448 as missing, and node:https client requests are on with nodejs_compat from compatibility date 2025-08-15. I could not run workerd on the test machine, so I have not tested web-push inside a Worker either way.

I still wrote the sender on Web Crypto. It needs no flag and no dependencies (web-push brings five), the same file ran in Node for every test below and type-checks against the Workers types, and when a push fails I can see which byte is wrong.

The Setup

• Windows 11 Pro, Node 25.2.1.
• The installed Chrome 155.0.8059.40 and Edge 155.0.4283.45, each on its own test profile, headless, driven over the Chrome DevTools Protocol.
• A test page on http://localhost:8796. Localhost counts as a secure context, so service workers and push work there without HTTPS.
• Notification permission granted by the test with Browser.grantPermissions, so no prompt was ever shown.
• A throwaway VAPID key pair, made for the test and deleted after it.
• The Worker handler below, called from a small Node server with a KV stand-in. wrangler dev does not run on this machine (its application control policy blocks workerd), so the handler was not deployed.

To see what arrived, I logged the service worker's console and turned on recording in the Background Services panel through CDP (BackgroundService.setRecording). The browser then logs "Push message received" and "Notification displayed" with the decrypted payload, and keeps that log across restarts, which is how I know which TTL messages arrived. Both browsers ran headless, so no Windows notification was ever drawn on screen.

Step 1: Make a VAPID Key Pair

VAPID is an ECDSA P-256 key pair. The browser gets the public half when it subscribes, and every send is signed with the private half. These are the lines from my test's key script:

const pair = await crypto.subtle.generateKey({ name: 'ECDSA', namedCurve: 'P-256' }, true, ['sign', 'verify']);
const keys = {
  publicKey: toB64u(new Uint8Array(await crypto.subtle.exportKey('raw', pair.publicKey))),
  privateKey: (await crypto.subtle.exportKey('jwk', pair.privateKey)).d,
  subject: 'mailto:push-test@example.com',
  sendToken: toB64u(crypto.getRandomValues(new Uint8Array(24))),
};

That is the format the web-push command line tool prints: an 87-character public key and a 43-character private key, both base64url. A pair from web-push's generateVAPIDKeys() signed correctly with my module in the tests below, so existing keys carry over. Keep them once you ship: every subscription is bound to the public key, and both push services refused a message signed with a different one. Store the private key as a secret (wrangler secret put VAPID_PRIVATE_KEY) and put a real contact in the subject.

Step 2: Subscribe in the Browser

The page registers a service worker, checks permission and calls PushManager.subscribe() with the VAPID public key. userVisibleOnly: true is the promise to show a notification for every push. Then it posts the subscription to the Worker:

// push.js: register the service worker, check permission, subscribe, and hand the subscription to the Worker.
// Call subscribe() from a click handler: browsers may ignore or quietly block a permission request without one.
function keyBytes(b64u) {
  return Uint8Array.from(atob(b64u.replace(/-/g, '+').replace(/_/g, '/')), (c) => c.charCodeAt(0));
}

export async function subscribe() {
  if (!('serviceWorker' in navigator) || !('PushManager' in window)) throw new Error('Web Push is not supported here');
  const reg = await navigator.serviceWorker.register('/sw.js');
  await navigator.serviceWorker.ready;
  if ((await Notification.requestPermission()) !== 'granted') throw new Error('notification permission not granted');
  let sub = await reg.pushManager.getSubscription();
  if (!sub) {
    const key = await (await fetch('/push/key')).text();
    sub = await reg.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey: keyBytes(key) });
  }
  const res = await fetch('/push/subscribe', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(sub) });
  if (!res.ok) throw new Error(`storing the subscription failed: ${res.status}`);
  return sub;
}

export async function unsubscribe() {
  const reg = await navigator.serviceWorker.ready;
  const sub = await reg.pushManager.getSubscription();
  return sub ? sub.unsubscribe() : false;
}

The service worker shows the notification and tells any open tab:

// sw.js: show a notification for every push, and tell open tabs about it.
self.addEventListener('push', (event) => {
  const text = event.data ? event.data.text() : null; // null when the push had no payload
  console.log('push received', JSON.stringify(text));
  let msg = {};
  try {
    msg = text ? JSON.parse(text) : {};
  } catch {
    msg = { body: text };
  }
  event.waitUntil((async () => {
    // userVisibleOnly: true means every push must show a notification.
    await self.registration.showNotification(msg.title ?? 'New update', { body: msg.body ?? '', tag: msg.tag, data: { url: msg.url ?? '/' } });
    for (const client of await self.clients.matchAll({ includeUncontrolled: true })) client.postMessage({ type: 'push', text });
  })());
});

self.addEventListener('notificationclick', (event) => {
  event.notification.close();
  event.waitUntil(self.clients.openWindow(event.notification.data.url));
});

Chrome returned an endpoint of the form https://fcm.googleapis.com/fcm/send/<token> with a 152-character token. Edge returned https://wns2-db5p.notify.windows.com/w/?token=<token> with a 328-character token. Both had expirationTime: null, a 65-byte p256dh key and a 16-byte auth secret. The whole subscribe() call took 1.7 s in Chrome and 1.0 s in Edge, one run each.

Step 3: The Send Module

This is the whole module, the file I type-checked and ran for every test in this post:

// webpush.ts: send one Web Push message with Web APIs only (fetch and crypto.subtle).
// The same file is written for a Cloudflare Worker and runs unchanged in Node (tested on 25).
// RFC 8030 (delivery headers), RFC 8291 + RFC 8188 (aes128gcm payload), RFC 8292 (VAPID).

export interface Subscription {
  endpoint: string;
  keys: { p256dh: string; auth: string };
}
export interface Vapid {
  publicKey: string; // base64url, 65-byte uncompressed P-256 point (what the browser gets)
  privateKey: string; // base64url, 32-byte private scalar "d" (the web-push CLI format)
  subject: string; // mailto: or https: contact for the push service
}
export interface PushOptions {
  ttl?: number; // seconds the push service may hold the message; WNS (Edge) rejected 0 with a 400, 1 worked
  urgency?: 'very-low' | 'low' | 'normal' | 'high';
  topic?: string; // up to 32 base64url chars; replaces an undelivered message with the same topic
}

const enc = new TextEncoder();
export const MAX_PLAINTEXT = 3993; // 4096 minus header (86), padding delimiter (1) and GCM tag (16)

export function toB64u(bytes: Uint8Array): string {
  let s = '';
  for (const b of bytes) s += String.fromCharCode(b);
  return btoa(s).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
}

export function fromB64u(s: string): Uint8Array {
  return Uint8Array.from(atob(s.replace(/-/g, '+').replace(/_/g, '/')), (c) => c.charCodeAt(0));
}

function concat(...parts: Uint8Array[]): Uint8Array {
  const out = new Uint8Array(parts.reduce((n, p) => n + p.length, 0));
  let i = 0;
  for (const p of parts) {
    out.set(p, i);
    i += p.length;
  }
  return out;
}

// VAPID (RFC 8292): an ES256 JWT for the push service's origin, signed with the application server key.
export async function signVapidJwt(claims: { aud: string; exp: number; sub: string }, vapid: Vapid): Promise<string> {
  const pub = fromB64u(vapid.publicKey);
  if (pub.length !== 65 || pub[0] !== 4) throw new Error('VAPID public key must be a 65-byte uncompressed P-256 point');
  const key = await crypto.subtle.importKey(
    'jwk',
    { kty: 'EC', crv: 'P-256', x: toB64u(pub.slice(1, 33)), y: toB64u(pub.slice(33)), d: vapid.privateKey },
    { name: 'ECDSA', namedCurve: 'P-256' },
    false,
    ['sign'],
  );
  const unsigned = `${toB64u(enc.encode(JSON.stringify({ typ: 'JWT', alg: 'ES256' })))}.${toB64u(enc.encode(JSON.stringify(claims)))}`;
  // Web Crypto returns the raw 64-byte r||s signature that JWS wants (Node's crypto.sign defaults to DER).
  const sig = await crypto.subtle.sign({ name: 'ECDSA', hash: 'SHA-256' }, key, enc.encode(unsigned));
  return `${unsigned}.${toB64u(new Uint8Array(sig))}`;
}

export async function vapidAuthorization(endpoint: string, vapid: Vapid, now = Date.now()): Promise<string> {
  const exp = Math.floor(now / 1000) + 12 * 60 * 60; // RFC 8292 allows at most 24 hours
  const jwt = await signVapidJwt({ aud: new URL(endpoint).origin, exp, sub: vapid.subject }, vapid);
  return `vapid t=${jwt}, k=${vapid.publicKey}`;
}

async function hkdf(salt: Uint8Array, ikm: Uint8Array, info: Uint8Array, bytes: number) {
  const key = await crypto.subtle.importKey('raw', ikm, 'HKDF', false, ['deriveBits']);
  return new Uint8Array(await crypto.subtle.deriveBits({ name: 'HKDF', hash: 'SHA-256', salt, info }, key, bytes * 8));
}

// RFC 8291: encrypt for one subscription. `fixed` exists only so a test can reproduce the RFC's example.
export async function encryptPayload(
  plaintext: Uint8Array,
  sub: Subscription,
  fixed?: { salt: Uint8Array; keys: CryptoKeyPair },
): Promise<Uint8Array> {
  if (plaintext.length > MAX_PLAINTEXT) throw new Error(`payload is ${plaintext.length} bytes, max ${MAX_PLAINTEXT}`);
  const uaPublic = fromB64u(sub.keys.p256dh);
  const authSecret = fromB64u(sub.keys.auth);
  const salt = fixed?.salt ?? crypto.getRandomValues(new Uint8Array(16));
  const as = fixed?.keys ?? ((await crypto.subtle.generateKey({ name: 'ECDH', namedCurve: 'P-256' }, true, ['deriveBits'])) as CryptoKeyPair);
  const asPublic = new Uint8Array((await crypto.subtle.exportKey('raw', as.publicKey)) as ArrayBuffer);
  const uaKey = await crypto.subtle.importKey('raw', uaPublic, { name: 'ECDH', namedCurve: 'P-256' }, false, []);
  // workers-types names this field `$public`; workerd strips the `$`, so the runtime reads the standard `public`.
  const ecdh = { name: 'ECDH', public: uaKey };
  const ecdhSecret = new Uint8Array(await crypto.subtle.deriveBits(ecdh, as.privateKey, 256));

  const ikm = await hkdf(authSecret, ecdhSecret, concat(enc.encode('WebPush: info\0'), uaPublic, asPublic), 32);
  const cek = await hkdf(salt, ikm, enc.encode('Content-Encoding: aes128gcm\0'), 16);
  const nonce = await hkdf(salt, ikm, enc.encode('Content-Encoding: nonce\0'), 12);
  const aes = await crypto.subtle.importKey('raw', cek, 'AES-GCM', false, ['encrypt']);
  // One record: the plaintext, then the 0x02 delimiter that marks the last record (RFC 8188).
  const ciphertext = await crypto.subtle.encrypt({ name: 'AES-GCM', iv: nonce }, aes, concat(plaintext, new Uint8Array([2])));

  // Header: salt (16) | record size (4, big-endian) | key id length (1) | key id = our ephemeral public key (65)
  const header = new Uint8Array(86);
  header.set(salt, 0);
  new DataView(header.buffer).setUint32(16, 4096);
  header[20] = 65;
  header.set(asPublic, 21);
  return concat(header, new Uint8Array(ciphertext));
}

export async function sendPush(sub: Subscription, payload: string | null, vapid: Vapid, opts: PushOptions = {}): Promise<Response> {
  if (opts.topic !== undefined && !/^[A-Za-z0-9_-]{1,32}$/.test(opts.topic)) throw new Error('Topic must be 1 to 32 base64url characters');
  const headers: Record<string, string> = {
    Authorization: await vapidAuthorization(sub.endpoint, vapid),
    TTL: String(opts.ttl ?? 86400),
  };
  if (opts.urgency) headers.Urgency = opts.urgency;
  if (opts.topic) headers.Topic = opts.topic;
  let body: Uint8Array | null = null;
  if (payload !== null) {
    body = await encryptPayload(enc.encode(payload), sub);
    headers['Content-Encoding'] = 'aes128gcm';
    headers['Content-Type'] = 'application/octet-stream';
  }
  return fetch(sub.endpoint, { method: 'POST', headers, body });
}

The VAPID Token

The JWT carries three claims. aud must be the origin of the endpoint (https://fcm.googleapis.com, not the full URL), exp must be less than 24 hours away, and sub is your contact. It goes in the RFC 8292 header vapid t=<jwt>, k=<public key>.

The trap in hand-written versions is the signature format. Web Crypto's ECDSA returns 64 raw bytes, r then s, which is what a JWT needs. Node's crypto.sign returns DER unless you pass dsaEncoding: 'ieee-p1363'. In my test, crypto.verify with the default encoding returned false for a valid token, and true with ieee-p1363.

The aes128gcm Body

Every message gets a fresh ECDH key pair and a random 16-byte salt. ECDH with the subscription's p256dh key gives a shared secret; HKDF with the auth secret and WebPush: info\0 plus both public keys gives the input key; two more HKDF calls give the 16-byte key and the 12-byte nonce. The plaintext gets a 0x02 byte and is encrypted with AES-GCM behind an 86-byte header. An empty payload makes a 103-byte body, so 3,993 bytes of plaintext fill the 4,096 a push service must accept. The module refuses more.

TTL, Urgency and Topic

TTL (RFC 8030) is how many seconds the push service may hold a message for an offline browser; I default to 86,400. Urgency is a hint for devices saving battery. Topic replaces an undelivered message with the same topic, so an offline phone gets the latest score instead of ten old ones. With both browsers online, Urgency: high and a Topic made no visible difference.

Want more like this?

New posts in your inbox, a few a month.

Email address subscribe

Website

By signing up you agree to receive articles, product news and offers from XNDR by email. We measure whether emails are opened and which links are clicked, and you can leave in one click. Privacy policy.

Step 4: The Worker

The handler stores subscriptions in KV under a SHA-256 of the endpoint, sends to all of them on an authenticated POST, and deletes a subscription only on 404 or 410:

// worker.ts: store push subscriptions in KV, send to all of them, and delete the ones the push service says are gone.
import { sendPush, type PushOptions, type Subscription } from './webpush.ts';

export interface Env {
  SUBSCRIPTIONS: KVNamespace;
  VAPID_PUBLIC_KEY: string;
  VAPID_PRIVATE_KEY: string; // wrangler secret put VAPID_PRIVATE_KEY
  VAPID_SUBJECT: string;
  SEND_TOKEN: string; // wrangler secret put SEND_TOKEN; protects /push/send
}

// Only POST to real push services, never to whatever URL a client sends us.
// Chrome gave me fcm.googleapis.com and Edge *.notify.windows.com; the Apple and Mozilla hosts are from their docs.
const PUSH_HOSTS = [/^fcm\.googleapis\.com$/, /\.notify\.windows\.com$/, /\.push\.apple\.com$/, /^updates\.push\.services\.mozilla\.com$/];

async function sha256hex(s: string): Promise<string> {
  const d = new Uint8Array(await crypto.subtle.digest('SHA-256', new TextEncoder().encode(s)));
  return [...d].map((b) => b.toString(16).padStart(2, '0')).join('');
}

function isSubscription(x: unknown): x is Subscription {
  const s = x as Subscription;
  if (typeof s?.endpoint !== 'string' || typeof s.keys?.p256dh !== 'string' || typeof s.keys?.auth !== 'string') return false;
  const url = URL.parse(s.endpoint);
  return url?.protocol === 'https:' && PUSH_HOSTS.some((h) => h.test(url.hostname));
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const { pathname } = new URL(request.url);

    if (request.method === 'GET' && pathname === '/push/key') return new Response(env.VAPID_PUBLIC_KEY);

    if (request.method === 'POST' && pathname === '/push/subscribe') {
      const sub: unknown = await request.json().catch(() => null);
      if (!isSubscription(sub)) return new Response('bad subscription', { status: 400 });
      const { endpoint, keys } = sub;
      await env.SUBSCRIPTIONS.put(`sub:${await sha256hex(endpoint)}`, JSON.stringify({ endpoint, keys }));
      return new Response(null, { status: 201 });
    }

    if (request.method === 'POST' && pathname === '/push/send') {
      // Compare digests, not the raw strings, so the check does not leak the token through timing.
      if ((await sha256hex(request.headers.get('Authorization') ?? '')) !== (await sha256hex(`Bearer ${env.SEND_TOKEN}`))) {
        return new Response('forbidden', { status: 403 });
      }
      const { payload = null, ...opts } = await request.json<{ payload?: string | null } & PushOptions>();
      const vapid = { publicKey: env.VAPID_PUBLIC_KEY, privateKey: env.VAPID_PRIVATE_KEY, subject: env.VAPID_SUBJECT };
      const results: { host: string; status: number; removed: boolean }[] = [];
      let cursor: string | undefined;
      do {
        const page = await env.SUBSCRIPTIONS.list({ prefix: 'sub:', cursor });
        for (const { name } of page.keys) {
          const sub = await env.SUBSCRIPTIONS.get<Subscription>(name, 'json');
          if (!sub) continue;
          const res = await sendPush(sub, payload, vapid, opts);
          await res.body?.cancel();
          // 404 and 410 mean the subscription is gone for good. Anything else: keep it and look at the status.
          const removed = res.status === 404 || res.status === 410;
          if (removed) await env.SUBSCRIPTIONS.delete(name);
          results.push({ host: new URL(sub.endpoint).host, status: res.status, removed });
        }
        cursor = page.list_complete ? undefined : page.cursor;
      } while (cursor);
      return Response.json(results);
    }

    return new Response('not found', { status: 404 });
  },
} satisfies ExportedHandler<Env>;

Three choices in it matter more than the rest:

• It only accepts endpoints on known push hosts. Without that check, anyone can make your Worker POST to any URL. In the test, a subscription pointing at another host got a 400.
• /push/send needs a bearer token. Without it the handler returned 403. For a public endpoint that has to accept signed requests from clients, the leaderboard anti-cheat post shows signatures with replay protection.
• Only 404 and 410 delete. A 400, 401 or 403 means my request was wrong. Deleting on those would wipe live subscribers because of a bug in the sender.

The type check failed first. With tsc --strict (TypeScript 7.0.2) against @cloudflare/workers-types 5.20261012.1, the ECDH call stopped at:

webpush.ts(84,84): error TS2561: Object literal may only specify known properties, but 'public' does not exist in type 'SubtleCryptoDeriveKeyAlgorithm'. Did you mean to write '$public'?

The Workers types call the field $public. In workerd's source the leading $ is stripped in the JavaScript binding (it is there because public is a C++ keyword), so the runtime reads the standard public. Passing the algorithm as a variable instead of an object literal satisfies the Workers types and the DOM types without a cast. Two narrower Uint8Array<ArrayBuffer> annotations failed as well; plain Uint8Array fixed them. After that, both files type-checked with no errors.

Every Worker push in the table went through this handler, called from Node. The response after the Chrome subscription was gone:

[{"host":"fcm.googleapis.com","status":410,"removed":true}]

Testing the Crypto Before Touching a Browser

A wrong byte in an info string does not produce an error on your server. The push service accepts the message and the browser drops it. So I tested the crypto first, against code that shares nothing with mine:

• RFC 8291's worked example. With the RFC's keys and salt, the module produces the RFC's message byte for byte. It is 144 bytes. The RFC's HTTP example says Content-Length: 145, which is erratum 5230; my first version of the test asserted 145 because I copied it from there.
• An independent receiver written with node:crypto (createECDH, hkdfSync, createDecipheriv) decrypts the RFC message, random payloads from 0 to 3,993 bytes, and the ciphertext from web-push 3.6.7.
• The JWT verifies with node:crypto, and web-push signs the same claims with a signature that verifies with the same public key.

PASS  RFC 8291 example, byte for byte  144 bytes
PASS  independent decrypt of the RFC message
PASS  round trip 0 bytes (body 103)
PASS  round trip 1 bytes (body 104)
PASS  round trip 100 bytes (body 203)
PASS  round trip 3993 bytes (body 4096)
PASS  3994 bytes refused  payload is 3994 bytes, max 3993
PASS  web-push 3.6.7 ciphertext decrypts with the independent receiver
PASS  header shape vapid t=<jwt>, k=<key>
PASS  JWT header
PASS  aud is the push service origin
PASS  exp is 12 h after now
PASS  signature is 64 raw bytes
PASS  node:crypto verifies it (ieee-p1363)
PASS  node:crypto default (DER) does not accept it  false
PASS  web-push header has the same k=
PASS  web-push JWT header and claims decode the same  {"aud":"https://fcm.googleapis.com","exp":1791892800,"sub":"mailto:push-test@example.com"}
PASS  web-push signature verifies with our public key
PASS  signatures differ (ECDSA is randomized)
PASS  web-push generate-vapid-keys output signs and verifies

all passed

What Chrome and Edge Actually Did

Edge Uses WNS, Not FCM

Edge 155 on Windows 11 gave me an endpoint on wns2-db5p.notify.windows.com, the Windows Push Notification Services. One detailed guide shows an Edge subscription under FCM in its example; that is not what I got. Plan for both hosts. A WNS success looks like this (the location path removed):

HTTP 201
content-length: 0
date: Tue, 13 Oct 2026 00:17:05 GMT
location: https://wns2-db5p.notify.windows.com/<path>
ms-cv: 1al2pW31rEm6YBGCVvg3vw.0
x-wns-debug-trace: DB5PEPF00014387
x-wns-msg-id: 1E736F8B29E61019
x-wns-notificationstatus: received
x-wns-status: received

Auth Errors: 403 With a Body, or 401 With a Header

The same three mistakes, with the exact text each service sent back:

• Wrong aud. FCM, 403 in the body: "permission denied: aud claim in the token MUST include the origin of the push resource URL". WNS, 401 in x-wns-error-description: "JWT Token missing Audience claim or Audience cliam doesn't match request host" (their spelling).
• Expired token. FCM 403: "permission denied: invalid JWT provided". WNS 401: "Token expired".
• Another VAPID key. FCM 403: "the VAPID credentials in the authorization header do not correspond to the credentials used to create the subscriptions." WNS 401: "The public key used to sign JWT does not match with the one included in channel Url."

WNS sent an empty body every time, so log response headers, not just bodies. The last case is also good news: a leaked subscription is useless without your private key.

TTL 0 Is a 400 on Edge

TTL: 0 means "deliver now or not at all". FCM accepted it with 201 while Chrome was closed, and the message never arrived after I reopened Chrome. A TTL 600 message sent in the same second arrived 3.1 s after the restart. WNS refused TTL 0 outright, with Edge closed and again with Edge open:

HTTP 400
x-wns-error-description: Ttl value conflicts with X-WNS-Cache-Policy.
x-wns-notificationstatus: dropped
x-wns-status: dropped

TTL: 1 to the open Edge was accepted and delivered. If your code sends 0, send 1 to WNS endpoints instead. A TTL 600 message to the closed Edge arrived 2.3 s after the restart.

201 Does Not Mean Delivered

Three times a push service answered 201 and nothing reached the page:

• TTL 0 to a closed Chrome, above.
• An unsubscribed endpoint. After unsubscribe() resolved true, FCM answered 201 four seconds later and 410 "push subscription has unsubscribed or expired." two minutes later, at which point the Worker deleted it. WNS answered 201 at four seconds, two minutes and 15 minutes, and Edge, still running, never dispatched them.
• A 4,200-byte body of random bytes. FCM refused it with 400 "binary data passed in the request must be less than 4096 bytes." WNS accepted it with 201, and Edge dropped it with "The public key included in the binary message header must be a valid P-256 ECDH uncompressed point that is 65 bytes in length." The most detailed guide I read lists 413 for an oversized payload; neither service sent me one.

So when a user turns notifications off, delete the subscription on your side at the same time. On Edge you may never get the 410 that the cleanup code waits for.

The Old Authorization Header Still Worked

Before RFC 8292 the header was Authorization: WebPush <jwt> with Crypto-Key: p256ecdsa=<key>. One post reports FCM rejecting that form with a 403. On 2026-10-13, with an aes128gcm body, both FCM and WNS accepted it and delivered the message. Send vapid t=..., k=...: it is the standard, and it worked on both.

What I Did Not Test

• Firefox and Safari were not tested, on any platform. iOS was not tested. Neither were Android or macOS, or Edge outside Windows. The Apple and Mozilla hosts in the allow list come from their documentation.
• A deployed Worker. The handler ran in Node with a KV stand-in, and the Workers runtime was never involved.
• Notifications on screen. Both browsers ran headless, so I have the browser's logs, not a screenshot of a Windows notification.
• Rate limits and server errors. 29 pushes in 25 minutes produced no 429 and no 5xx.
• Topic replacement and Urgency with a browser offline.

Push services change without notice, which is why every response here carries a date. If you want push notifications, or another Worker feature, built and tested this way before launch, that is the work on our services page. The AI Gateway post follows the same habit of reading every response header.

FAQ

Does the web-push npm package work on Cloudflare Workers?

Cloudflare's own push notifications guide, updated 2026-10-12, uses it in a Worker with the nodejs_compat flag. I did not run it in workerd myself. The Web Crypto module in this post needs no flag and no dependencies, and it reproduced the RFC 8291 example byte for byte.

What push service does Microsoft Edge use?

On Windows 11, Edge 155 gave me an endpoint on wns2-db5p.notify.windows.com (WNS) on 2026-10-13, not FCM. WNS reports errors in the x-wns-error-description header with an empty body, and it answered 401 where FCM answered 403.

Why does my push return 201 but no notification appears?

201 means accepted, not delivered. In my tests that happened for a TTL 0 message to a closed browser, for an endpoint that had been unsubscribed (FCM for two minutes, WNS for at least 15), and for a body the browser could not decrypt, which Edge dropped and logged in DevTools under Background Services.

Can I send a push with TTL 0?

To FCM, yes: it was accepted and dropped while Chrome was closed. To WNS, no: Edge endpoints answered 400 "Ttl value conflicts with X-WNS-Cache-Policy." with the browser closed and open. TTL: 1 was accepted and delivered.

When should I delete a push subscription?

On 404 or 410 only, and as soon as the user unsubscribes. FCM answered 410 for an unsubscribed and for a made-up endpoint, WNS answered 404 for a made-up one. A 400, 401 or 403 is a bug in your request, so keep the subscription and fix the sender.

Related Articles

• Cloudflare Workers Leaderboard API with Anti-Cheat
• Cloudflare AI Gateway for Claude and OpenAI: Cache, Limit, Fall Back
• Building a Telegram-to-CLI Bridge for Claude Code
• XNDR services: edge APIs and browser apps on Cloudflare.

Liked this one? Get the next in your inbox.

New posts and the odd product note, a few emails a month. Easy to leave.

Email address subscribe

Website

By signing up you agree to receive articles, product news and offers from XNDR by email. We measure whether emails are opened and which links are clicked, and you can leave in one click. Privacy policy.