What happens if I omit the optional Topic header?

Without a Topic header, the push service treats every message as independent. Providing a Topic enables message coalescing, replacing pending undelivered notifications with the newest update.

Web Push RFC 8030 Request + VAPID + RFC 8291 Payload Encryption Encoder | Online Free Tool

Web Push RFC 8030 Request + VAPID + RFC 8291 Payload Encryption Encoder | Online Free Tool | Elysia Tools

Tool usage guide

Learn when to use this tool, what it supports, and how real users apply it.

Key facts

Category: Format Conversion
Input types: textarea, select, text, number, checkbox
Output type: html
Sample coverage: 4
API ready: Yes

Overview

The Web Push RFC 8030 Request, VAPID, and RFC 8291 Payload Encryption Encoder generates standard-compliant HTTP push requests by performing ECDH key exchange, HKDF derivation, and payload encryption. It produces complete RFC 8030 headers, RFC 8292 VAPID authentication JWTs, cryptographic step-by-step traces, and cross-platform header mappings for APNs and FCM.

When to use

Debugging or building custom Web Push backend delivery pipelines that require byte-level verification against RFC 8291 and RFC 8292 specifications.
Validating encrypted payload construction (aes128gcm or legacy aesgcm) and verifying round-trip decryption against client subscription keys.
Mapping standard RFC 8030 Web Push headers (TTL, Urgency, Topic) to equivalent Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM) dispatch headers.

How it works

1Derives the shared secret via P-256 ECDH using the subscription public key (p256dh) and an ephemeral application-server private key, combining it with the subscription auth secret using HKDF-SHA256.
2Computes the Content Encryption Key (CEK) and nonce with the provided salt, then encrypts the plaintext payload using AES-128-GCM according to the chosen content coding (RFC 8291 aes128gcm or draft-04 aesgcm).
3Generates the ES256 VAPID Authorization JWT with audience, expiration, and subject claims, formatting the full HTTP/2 request with RFC 8030 headers (TTL, Urgency, Topic).
4Outputs an interactive diagnostic report detailing cryptographic intermediates (IKM, CEK, nonce), a round-trip decrypt check, and an APNs/FCM header translation table.

Use cases

Verifying in-house Web Push client/server implementations against official RFC reference vectors byte for byte.
Diagnosing push notification delivery failures and header mismatches across Chrome, Firefox, Safari, and mobile Web Push endpoints.
Inspecting intermediate key material (PRK, IKM, CEK, and nonce) during cryptographic auditing and security testing.

Examples

1. Encrypting a Standard Web Push Notification (RFC 8291 aes128gcm)

Backend Engineer

Background

An engineer is implementing an order status notification service and needs to generate an encrypted push payload compatible with modern browsers.

Problem

Verify that the backend's ECDH key agreement, HKDF derivation, and RFC 8188 payload structure match standard RFC 8291 outputs.

How to use

Enter the JSON payload, paste the subscription p256dh public key and auth secret, provide ephemeral P-256 keys, and configure TTL and urgency headers.

payload: '{"title":"Order shipped","id":48291}', encoding: 'aes128gcm', ttl: 60, urgency: 'normal', vapidSub: 'mailto:[email protected]'

Outcome

Generates the complete HTTP/2 POST request body with RFC 8188 binary headers, VAPID Authorization token, and an intermediate crypto trace.

2. Debugging Legacy Push Subscriptions with Round-Trip Decryption

Full-Stack Developer

Background

A developer maintains legacy browser clients that still negotiate draft-04 aesgcm encoding and wants to verify payload decryption locally.

Problem

Ensure that legacy Encryption and Crypto-Key headers correctly correspond to the aesgcm payload and decrypt reliably on the client.

FAQ

What is the difference between aes128gcm and legacy aesgcm content codings?

aes128gcm (RFC 8291) includes the salt, record size, and public key directly in the RFC 8188 binary body header, whereas legacy aesgcm (draft-04) passes salt and public key in separate Encryption and Crypto-Key HTTP headers.

Why is the subscription auth secret required for payload encryption?

The auth secret acts as an additional HKDF salt context ('WebPush: info') during key agreement to prevent man-in-the-middle attacks and ensure only the intended receiver can derive the CEK.

How does round-trip decrypt verification work?

When you provide the receiver's private key (uaPrivateKey), the tool executes the matching client-side decryption steps to verify that the ciphertext decodes back to the original plaintext.

Are the application server private key and VAPID private key the same?

No. The application server key (asPrivateKey) is an ephemeral P-256 key used solely for ECDH payload encryption, whereas the VAPID private key is a signing key used to generate the ES256 JWT Authorization header.

payload: 'Hello legacy client', encoding: 'aesgcm', paddingBytes: 2, topic: 'chat-update', urgency: 'high'

Web Push RFC 8030 Request + VAPID + RFC 8291 Payload Encryption Encoder

What this tool helps you do

Run this tool

Examples that match this tool

Continue with connected tools and hubs

Learn when to use this tool, what it supports, and how real users apply it.

Key facts

Overview

When to use

How it works

Use cases

Examples

1. Encrypting a Standard Web Push Notification (RFC 8291 aes128gcm)

2. Debugging Legacy Push Subscriptions with Round-Trip Decryption

FAQ

Web Image Processing Python Samples

Web Image Processing Rust Samples

Web Image Processing TypeScript Samples

Web File Operations Go Samples

Data URI Generator

Hash Algorithm Comparator

RSA Encrypt / Decrypt

OpenTelemetry W3C traceparent / tracestate / baggage + OTLP Header Propagation Validator