Not if you encrypt as RFC 8291 specifies. The scheme protects message content from inspection, modification and forgery by the push service. It does not hide metadata: the push service still sees when you send and how long the message is, unless you pad.
Definition
Message Encryption for Web Push, RFC 8291, defines how your server encrypts a payload so only the subscribed browser can read it. The push service relays ciphertext. This matters because RFC 8030 notes that keeping the push URL secret does not hide message content from the push service.
How the keys work
Each browser creates an elliptic curve key pair on P-256 and a random authentication secret for every subscription. The RFC requires the secret to be a hard-to-guess sequence of 16 octets. Your server uses these, plus its own key, to derive the encryption key with HKDF and SHA-256, and encrypts with the aes128gcm content coding.
The authentication secret must reach your server over an authenticated, confidentiality-protected channel. If it leaks, outsiders could forge messages the browser would accept. Handle it like the endpoint itself. See web push URLs as secrets.
What it protects and what it does not
| Property | Protected? |
|---|---|
| Message content from the push service | Yes |
| Modification or forgery by the push service | Yes |
| Timing of the message | No |
| Message length | Not unless you add padding |
| Who the sender is | Visible to the push service, especially if you use VAPID |
The RFC states that timing and length of communication cannot be hidden from the push service, and that padding can obscure length only if used.
Practical limits
A push service is not required to support more than 4096 octets of payload body. After the header, minimum padding and authentication tag, the RFC puts the maximum plaintext at 3993 octets. Keep notifications short. That is also a privacy habit: send an identifier and let the app fetch the detail after the user opens it, so sensitive text does not sit in a notification.
The RFC also bans other content encodings to avoid compression based leaks, and requires receivers to discard messages whose padding delimiter is wrong.
Steps
- Use a maintained library that implements RFC 8291 rather than writing the crypto yourself.
- Store the auth secret and public key with the subscription, protected like a credential.
- Validate that the browser public key is on the P-256 curve, as the RFC requires.
- Keep payloads small and put sensitive detail behind an authenticated fetch.
- Pad where message length itself would reveal something.
- Track the crypto library in your SBOM and watch advisories.
Where Safeguard fits
Safeguard's SBOM and dependency scanning lists the push and crypto libraries in your build and checks them against known advisories. The free scan is at https://gold.safeguard.sh/scan.
Quick check
If I encrypt, can I put anything in the notification?
Content is protected in transit, but it still appears on the device screen. Keep sensitive detail out of notification text.
Does encryption hide that I sent a message?
No. The push service can see timing and length.
Sources
Last reviewed: 19 October 2026.
