How to Test Browser Notification Permissions

Notifications work perfectly in development, because you granted permission on day one and never thought about it again. Then a user denies the prompt, and your code — which assumed granted or nothing — silently does neither.

There are three states, not two, and the one that breaks things is the one you can’t easily get back to.

The three states

default — no decision has been made. No prompt has been shown, or the user dismissed it without choosing. You may request permission.

granted — notifications will display.

denied — the user said no. You cannot request again. Calling the request method returns immediately with denied and shows nothing.

That last point is the important one. A denial is effectively permanent for that origin. The user can clear it in site settings, but nothing in your code can prompt them again, and most users never find that setting.

Which makes the prompt a one-shot resource, and spending it badly is a permanent cost.

When to ask

Not on page load. Browsers have progressively restricted unprompted permission requests: several now require a user gesture, some show a quieter interface for sites that ask immediately, and at least one blocks the prompt entirely for repeat offenders.

Beyond the technical restrictions, the acceptance rate for a prompt shown before any value has been demonstrated is famously poor.

The pattern that works is asking after the user does something that makes notifications obviously useful — subscribing to a thread, placing an order they’ll want updates on, starting a long-running job. At that moment the request makes sense, and the user has context for the decision.

What to test

All three states, not just granted. The denied path is where implementations break, and it’s the state you’ll have permanently once you test it — which is why a tool that lets you observe the behaviour is useful.

The fallback. When notifications are denied, does the feature still work through some other channel — an in-page indicator, an email, a badge? Or does it silently do nothing?

The permission check before requesting. Calling request when the state is already denied does nothing but waste a call; checking first lets you show something more useful.

Common mistakes to avoid

• Requesting permission on page load, which browsers penalise and users reject.
• Assuming a denial is temporary and re-prompting on every visit, which is impossible anyway and reads as hostile in the attempt.
• Treating default as denied — the user hasn’t refused, they haven’t been asked.
• Building the feature to depend entirely on notifications, so denial makes it useless.
• Testing only on a browser where you granted permission months ago.

How to do it with Notification Permission Tester

The Notification Permission Tester shows the current state and lets you exercise each path.

1. Read the current state first — default means no decision has been made.
2. Request permission from a user gesture and watch what the browser does.
3. Send a test notification and check tag behaviour, which controls whether notifications stack or replace.
4. Deliberately test the denied path in a separate profile, since you can’t undo it in the current one.

MDN’s Notifications API documentation covers the full interface. Other developer tools are in the tools directory.

Frequently asked questions

Why is my permission prompt not appearing?

Either permission was already decided, or the browser blocked it because the request wasn’t triggered by a user gesture. Several browsers now require an explicit interaction first.

Can I reset a denied permission?

Not from script — that’s the point of the denial. The user has to clear it in site settings, which is why a rejected prompt is effectively permanent for that visitor.

Should a site request notifications on load?

No. It has one of the worst acceptance rates of any prompt, and browsers penalise sites that do it. Ask after the user has done something that makes notifications obviously useful.

Final thought

You get one prompt per visitor, ever. Spend it at the moment the user would say yes, and build the feature so a no doesn’t break it.

Try the free Notification Permission Tester