What Are Push Notifications? How Web Push Works

What Are Push Notifications?

A push notification is a message that a server delivers to a user's device — phone, tablet, or desktop browser — without the user requesting it. Even when the page isn't open, the notification appears in the operating system's or browser's notification area. That's what sets push apart from the classic request-response model, where the user has to reload the page to see anything new.

There are two main types: app push notifications, which mobile apps send through the operating system, and web push notifications, which run through the browser. Because web push needs no installed app, it lets news sites reach a wide audience with no barrier to entry.

App Push vs. Web Push

Both approaches serve the same goal but rely on different plumbing. The table below sums up the key differences.

Web push is popular among publishers because it works without building a separate app. For it to pay off, your site also has to work flawlessly on mobile; see our piece on mobile-friendliness for news sites.

How Web Push Works: The Core Pieces

Web push is built on open standards that browsers support. Three main components work together:

• Service Worker: a script that runs in the background even when the page is closed. It catches the incoming push event and displays the notification.
• Push API: lets the browser subscribe to a push service and produce an endpoint (an address).
• Notification API: the layer that actually shows the notification on the user's screen.

The messages themselves travel over push services operated by the browser vendors — for example Firebase Cloud Messaging on the Chrome side, and Mozilla's own service on the Firefox side. As a site owner you don't choose which service is used; the browser decides that automatically and simply hands you an endpoint.

The Web Push Flow, Step by Step

A push notification's journey starts with the user granting permission and ends with the message appearing on screen:

• The user visits your site and you register a Service Worker.
• The user grants notification permission; the browser subscribes to a push service.
• The browser produces a subscription object containing a unique endpoint and encryption keys.
• That subscription is sent to your server and stored.
• When a new story breaks, your server sends the encrypted message to the relevant endpoint.
• The push service delivers the message to the user's browser.
• The Service Worker catches the push event and shows the notification with showNotification.

// Service Worker: catch the incoming push event and show the notification
self.addEventListener('push', (event) => {
  const data = event.data ? event.data.json() : {};
  const title = data.title || 'Breaking News';
  event.waitUntil(
    self.registration.showNotification(title, {
      body: data.summary,
      icon: '/icon-192.png',
      data: { url: data.url }
    })
  );
});

Delivery, like every other layer of content distribution, is shaped by speed and reliability. To sharpen server-side performance, the principles in our guide on what caching is and how it works will help.

Permission Handling and User Experience

The most delicate part of push is the permission prompt. Browsers ask for notification permission only once; if the user declines, most browsers won't let you ask again. That makes requesting it at the right moment, with the right reason, decisive.

Security: VAPID and Encryption

Web push rests on open standards that guarantee messages come from the right sender and can't be read in transit. Your server identifies itself to the push service using a public/private key pair known as VAPID (Voluntary Application Server Identification), which makes it far harder for others to abuse your endpoint.

The message content is encrypted end to end: the payload is encrypted with keys that come with the subscription, so the push service in the middle can't see what the message says. These mechanisms are defined in the relevant internet standards (RFC 8030, RFC 8291, and RFC 8292).

Best Practices for News Sites

Used well, push builds a loyal readership; overused, it drives unsubscribes and declined permissions. The practices that stand out:

• Relevance: notify users only about developments that are genuinely important or match their interests.
• Frequency capping: limit how many notifications you send per day; notification fatigue is the most common reason people opt out.
• Segmentation: offer topic-based subscriptions such as sports, business, or local news.
• Timing: send when the reader is active and while the story is still fresh.
• Clear headlines: use headlines that earn the click without misleading; clickbait wears down trust.

Push is just one of your distribution channels. For automated content syndication, consider RSS and XML feeds as a complement.

Frequently Asked Questions

Does web push work in every browser?

On desktop and Android, most major browsers support web push. On iOS and iPadOS, Safari supports web push only when the site is added to the home screen as a web app; this capability arrived with iOS 16.4.

Do I need a mobile app for push notifications?

No. Web push exists precisely to remove that need: once a user visits your site and grants permission, they can receive notifications without downloading an app from a store.

How can a user opt out?

A user can revoke permission at any time from the browser or site settings. A healthy system also offers an easy-to-find way to turn notifications off on your own site.