Online Tool Store Online Tool Store
🔔 Developer Tools

· 6 min read

3 Notification Permission Testers, Compared

Heshan Fernando

Co-founder & COO

Heshan Fernando is the Co-founder and Chief Operating Officer of Ceyentra Technologies, where he leads project management, engineering, and research and development strategy. With over nine years of industry experience, he is passionate about transforming complex customer challenges into practical, high-impact solutions. His customer-centric leadership has enabled multidisciplinary teams to consistently deliver secure, scalable, and industry-grade digital products that create lasting business value. View on LinkedIn

Share

3 Notification Permission Testers, Compared

You ship a notification prompt, click Allow while testing, and everything works. Then a user clicks Block, and your app spends the rest of its life calling requestPermission() and getting an instant denied with no dialogue ever appearing.

That is the part that goes untested. Permission has three states — default, granted and denied — and only the first one produces a prompt. Once denied, the browser resolves the request silently, so a UI built around “the user will see a dialogue” quietly does nothing at all. Testing means putting yourself deliberately in the states you did not choose.

How to judge a notification tester

Does it report the current state? Notification.permission is the ground truth. Seeing it plainly is the starting point.

Can you customise the notification? Title, body, icon, tag and actions all behave differently across platforms, and tag replacement in particular surprises people.

Does it cover push, or only local? A local new Notification() and a real push through a service worker are different mechanisms with different failure modes.

Does it stay client-side? For local notification testing there is no reason for a server to be involved.

The comparison

ToolBest forFree tierWatch out
FreeTool24 Notification TesterExercising every notification optionFree, zero server callsLocal notifications, not push
Push.FooReal Web Push across devicesFree, open sourcePush involves a server by definition
MagicBell Web Push TestChecking Safari and iOS behaviourFree to usePart of a commercial product

Facts checked August 2026; tools change their plans. Table covers only the 3 alternatives — our tool gets its own section below.

FreeTool24 Notification Tester

The most thorough on the notification object itself. You can set title and body, icon, badge and image, a tag to replace previous notifications, a delay of up to 60 seconds, silent mode, vibration settings and interaction requirements — then see exactly how the result renders. Preset templates cover simple, chat message and alert shapes, and it generates the corresponding JavaScript to copy.

That delay setting is more useful than it looks: it lets you trigger a notification and then switch to another tab or app to see how it appears when your page is not focused, which is the situation notifications actually exist for. Everything runs client-side with zero server calls and no account.

Push.Foo

The one that tests real push. It demonstrates the Web Push API with instant notifications on a single device and multi-device push scenarios, letting you configure title, body, icon, badge and language. Device registration with user-defined tags is optional and exists for the multi-device case.

Free and open source. Push is fundamentally different from a local notification — it involves a service worker, a subscription and a push service — so if your feature sends notifications to users who are not currently on the page, this is the mechanism you need to test, and a local notification tester will not tell you anything about it.

MagicBell Web Push Test

The most useful for cross-platform checking. It covers Chrome, Firefox, Edge and Safari including macOS Ventura and later and iOS 16.4 and later, with a console showing SDK events in real time, and its service worker registers automatically.

The iOS detail is the reason to use it: on iOS, web push only works once the site is added to the home screen as a PWA, which is the single most common reason a notification feature “does not work on iPhone”. No account is needed for the test page. It is produced by a notifications company, so the surrounding pages are a product funnel.

Notification Permission Tester

Ours checks the current notification permission state, requests it, and shows how a denied or default state behaves before you ship a prompt. That last part is the design intent — the failure mode worth rehearsing is not the happy path, it is what your interface does when the answer is no and no dialogue ever appears.

What it does not do: send real push notifications through a service worker, or exercise every notification option. For push, Push.Foo or MagicBell are the right tools; for tag behaviour and vibration patterns, FreeTool24 goes further. MDN’s Notifications API documentation covers the states and their behaviour precisely, including that repeatedly dismissed prompts can cause a browser to block the site outright.

Which one to pick

  • How a notification renders with every option set — FreeTool24.
  • Real push to a device that is not on your page — Push.Foo.
  • Safari and iOS specifically — MagicBell.
  • What your UI does when permission is denied — the tool below.

How to do it with Notification Permission Tester

  1. Open the Notification Permission Tester and read the current state.
  2. Request permission and allow it, then confirm your flow works.
  3. Reset the site’s permission in browser settings and deny it, then run the same flow again — that is the untested path.
  4. Check that your interface explains what happened rather than waiting for a dialogue that will never appear.

The walkthrough is in how to test browser notification permissions. Other developer tools are in the tools directory.

You might also need

If your app also stores data locally, the IndexedDB Inspector covers what it has kept on the device.

The Browser Storage Quota Checker is worth a look for PWAs, where storage limits and notification permissions tend to be debugged in the same session.

Frequently asked questions

What are the three notification permission states?

default means the user has not decided, and it is treated as denied until they do. granted means allowed. denied means blocked — and in that state requestPermission() resolves immediately without showing anything.

Why does my permission prompt not appear?

Either permission is already denied, in which case the browser resolves silently, or you are requesting outside a user gesture. Browsers increasingly require a click or tap before showing the dialogue, and some block sites that repeatedly prompt and get dismissed.

Why don’t notifications work on iPhone?

Web push on iOS requires the site to be installed to the home screen as a PWA, and iOS 16.4 or later. A site opened in Safari as a normal tab cannot receive web push, which accounts for most reports of notifications “not working on iOS”.

Final thought

Test the denied path first, because it is the one you will never encounter by accident. Everyone clicks Allow on their own site, and everyone ships an interface that assumes a dialogue is coming.

Try the free Notification Permission Tester

#notification-permission#web-notifications-api#push-testing#alternatives#online-tools#free-tools