Notification Permission Tester
Check the current notification permission state, request it, and see how a denied or default state behaves before shipping a prompt.
🔒 This tool runs entirely in your browser. Your files are never uploaded to a server.
Developer
Notification Permission Tester
Frontend preview — no upload or external service.
Permission state
Current state: "default" — no prompt has been shown. After requesting: "granted". A test notification fires with tag "test", which replaces rather than stacks.
How the Notification Permission Tester works
- Read the current state first; "default" means no decision has been made yet.
- Request permission from a user gesture, not on page load — browsers increasingly block or penalise unprompted requests.
- Test the denied path deliberately, since that is the state your code most often handles badly.
FAQ
Why is my permission prompt not appearing?
Either permission was already decided, or the browser blocked it because the request was not triggered by a user gesture. Several browsers now require an explicit interaction first.
Can I reset a denied permission?
Not from script — that is 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.
How we compare
| Feature | Online Tool Store | A CLI script | An IDE plugin |
|---|---|---|---|
| Shows all three states | ✓ | ✓ | Varies |
| Tests the denied path | ✓ | Manual | ✓ |
| No install | ✓ | ✗ | ✓ |
| Resets a denial | ✗ | ✗ | ✗ |
Notification Permission Tester makes the denied path easy to exercise, which is the state most implementations handle worst and users most often produce.