VAPID Keys Explained: How Web Push Authentication Actually Works

If you have ever set up web push notifications, you have run into the acronym VAPID — usually when a setup screen asks you to paste a "public key" and a "private key." It looks like security plumbing you are supposed to copy and forget. But understanding what VAPID does makes the whole web push flow click into place, and it explains one of the best things about web push on the open web: you do not need Firebase at all.

This guide walks through what VAPID is, what the keys do, and how the browser, your server, and the push service all agree on who is allowed to send a notification.

What VAPID stands for

VAPID is short for Voluntary Application Server Identification for Web Push. It is an open standard (RFC 8292) that lets your server prove its identity to a browser's push service.

Here is the core problem it solves. When a user subscribes to push notifications, the browser hands you a subscription endpoint — a URL hosted by a push service like Mozilla's, Google's, or Microsoft's. Anyone who steals that endpoint could, in theory, blast notifications at the user. VAPID closes that gap by requiring every push request to be signed by the application server that owns the subscription.

No signature, or the wrong signature, and the push service rejects the message.

The public/private key pair

VAPID uses standard public-key cryptography, specifically an elliptic-curve key pair (P-256). You generate this pair once and reuse it across all your subscribers.

• Private key — stays secret on your server. You use it to cryptographically sign every push request.
• Public key — shared openly. The browser stores it at subscribe time, and the push service uses it to verify your signatures.

The flow looks like this:

1. The browser subscribes the user, passing your public key as the applicationServerKey.
2. The push service ties that subscription to your public key.
3. When you send a push, your server signs a token (a JWT) with your private key.
4. The push service checks the signature against the stored public key. Match means deliver; mismatch means reject.

Because only you hold the private key, only you can produce valid signatures. Even if someone scrapes an endpoint, they cannot forge a message.

The application server key

That applicationServerKey you pass during subscription is just your VAPID public key, formatted in a browser-friendly way (URL-safe base64, the uncompressed P-256 point). The browser does not let you subscribe to push without it — it is the anchor that links a subscription to your identity.

A common gotcha: if you change your VAPID keys later, existing subscriptions break. They were created against the old public key, so signatures from a new private key will not verify. Generate your keys once, store them safely, and treat them like long-lived credentials.

The JWT: how a signed push looks

When your server sends a notification, it attaches an Authorization header containing a JWT with three claims:

• aud — the origin of the push service (derived from the endpoint URL).
• exp — an expiry timestamp, usually a few hours out, so signatures cannot be replayed forever.
• sub — a contact, either a mailto: address or your site URL, so the push service can reach you if your traffic misbehaves.

That token is signed with your private key. The service for Chrome, Firefox, Edge, and Safari all understand it — VAPID is a shared standard, not a vendor feature.

Why no Firebase is needed

Plenty of older tutorials route web push through Firebase Cloud Messaging (FCM). That was historically how Chrome handled delivery, and it left people thinking a Google project is mandatory.

It is not. Modern browsers speak the standardized Web Push Protocol directly, and VAPID is the authentication layer for it. With a VAPID key pair you can:

• Send to Chrome, Firefox, Edge, Opera, and Safari from the same code path.
• Skip Firebase project setup, SDKs, and sender IDs entirely.
• Own your subscriptions outright, with no third-party messaging account in the middle.

Your stack becomes refreshingly small: a service worker to receive and display notifications, a subscription captured after a clean opt-in prompt, and a server that signs requests with VAPID.

Putting it together

The mental model is short:

• VAPID identifies your server to the push service.
• The public key travels with the subscription; the private key signs every send.
• Generate the pair once, guard the private key, never rotate casually.
• No FCM, no vendor lock-in — just open web standards.

This is exactly the kind of setup relaybell handles for you. It generates and manages your VAPID keys, ships a ready-made service worker, and gives you a clean opt-in flow — so you can start sending standards-based web push in minutes instead of wiring up crypto by hand. Once subscribers are in, you can segment them and watch click-through rate, which for well-targeted web push commonly lands in the low-single-digit to high-single-digit percent range.

Web push is one of the few channels where the underlying tech is genuinely open, free to deliver on, and yours to keep. VAPID is the small but essential piece that makes that trust model work.

Ready to try web push? Get started with relaybell — free to deliver, live in minutes.