A notification interrupts. A badge waits. That small distinction is why unread counters appear on mail, messaging, and task apps: they communicate that something changed without placing a banner over the work already on screen. The Badging API gives installed web apps a browser-mediated way to use the same restrained signal.
The capability is simple, but it sits inside a larger question about attention. A number on an app icon can be useful status, an anxious obligation, or an engagement trick. The API supplies the mechanism. Product choices determine which one it becomes.
Badging API adds status to a web app icon
The Badging API lets a web application ask the browser or operating system to place a badge on its app icon. A site can set a number, request a neutral flag without a number, and clear the badge when the state is resolved.
In supporting browsers, navigator.setAppBadge(3) can communicate three pending items. Calling navigator.setAppBadge() without a value requests a flag-style indicator. navigator.clearAppBadge() removes it.
The browser decides how the signal appears. One operating system may show a number in a corner, another may use a dot, and another may suppress the badge under local settings. The W3C Badging API specification deliberately gives user agents room to follow platform conventions.
Badges are quieter than notifications
A notification asks for immediate attention. It can appear over another application, make a sound, remain in a notification centre, or reach someone after the original page has closed. A badge changes a visual property of the app's own icon and waits to be noticed.
That makes badges suitable for non-urgent state: unread conversations, unfinished uploads, assigned tasks, or items waiting for review. None of those necessarily deserves an interruption the moment it changes.
Badges and notifications can still work together. An urgent incoming call might justify a notification, while the count of missed conversations remains on the icon afterward. The design mistake is treating every counter increase as permission to interrupt.
Support and installation shape what users see
The Badging API has limited availability. It is exposed only in secure contexts, and the most complete experience is associated with installed progressive web apps. Support varies across browsers and operating systems, so developers need a fallback that does not hide important state.
An app should always show the same pending information inside its own interface. The badge is a convenience, not the only record. A person who disables badges, uses an unsupported browser, or opens the site in a regular tab must still be able to find unread or unfinished work.
Installation itself is controlled separately through the web app manifest. Our guide to how websites become installed apps explains how a manifest supplies the name, icon, launch URL, and scope used by the operating system.
Background updates need a separate mechanism
The Badging API changes an indicator; it does not independently wake a closed application or fetch new data. A service worker, push message, periodic task, or foreground network request may provide the event that causes the app to update its badge.
This separation matters for privacy. A visible count may be the final output of background communication, but it does not explain how often the app contacts a server or what data travels in those requests. Evaluate the update channel as well as the icon.
Our article on the Browser Push API covers subscriptions, service workers, and encrypted delivery. The guide to service workers explains why web apps can keep handling selected events beyond the life of one visible page.
Counts can reveal more than designers expect
A badge may be visible on a shared desktop, projected screen, or locked device. A number alone does not expose message content, but it can reveal that activity exists and how quickly it accumulates. For some products, even that is sensitive.
Developers should avoid encoding categories or private meaning into badge values. A neutral dot can be better than a precise number when the important fact is simply that the app needs attention. The interface inside the app can reveal details after the user chooses to open it.
Stale badges create a different problem. A counter that remains after work is completed trains people to ignore the signal. Clear it promptly when the relevant state is read, dismissed, or resolved, and reconcile the value across devices rather than letting old numbers linger.
Good badge design respects attention
Start with a narrow definition of what deserves a badge. “Anything new” is usually too broad. “Items the user must review” is clearer and easier to keep accurate.
Let people reduce or disable the signal. Some users want an exact unread count; others prefer a dot; others want no external indicator at all. Platform settings matter, but an in-app preference can make the product's intent clearer.
Do not manufacture counts to create urgency. Combining old promotions, suggested content, and routine updates into one large number makes the badge less trustworthy. A counter should describe state, not apply pressure.
Noorani takes the same view of browser attention. The article on why Noorani does not have a notification feed separates necessary alerts from an endless stream designed to be checked. Quiet software can still communicate; it simply waits for an appropriate moment.
A small API carries a large design choice
The Badging API is technically modest. It sets or clears a number or flag on an application icon, subject to browser and operating-system support. The deeper value is that it offers an alternative to interruption.
Used carefully, a badge helps people return to unfinished work on their own terms. Used carelessly, it becomes another red counter competing for the next glance. The difference is not in the method call. It is in the discipline behind the product.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.