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

Encode a complete Web Push send: RFC 8291 aes128gcm payload encryption, RFC 8292 VAPID ES256 JWT, RFC 8030 headers, APNs/FCM cross-walk and decrypt round-trip verification.

> Canonical page: https://elysiatools.com/en/tools/web-push-rfc8030-vapid-rfc8291-payload-encrypted-content-encoder

- **Category:** Format Conversion

- **Keywords:** web push encryption, rfc 8291 aes128gcm, vapid jwt, rfc 8292, rfc 8030 headers, p256dh auth secret, ecdh p-256 hkdf, apns headers, fcm collapse key, push round-trip

## Overview

Encryption follows RFC 8291 exactly: ECDH on P-256 between an ephemeral application-server key and the subscription p256dh key, HKDF-SHA256 key combining with the auth secret ("WebPush: info" context), a random 16-byte salt, CEK/nonce derivation via "Content-Encoding" contexts, and AES-128-GCM with the RFC 8188 binary header (salt + record size + key id). The implementation reproduces the RFC 8291 §5 and draft-ietf-webpush-encryption-04 worked examples byte for byte.

## Inputs

- **Payload (plaintext)** (textarea): Message body sent to the user agent, e.g. {"title":"Order shipped"}
- **Content coding** (select)
- **Subscription p256dh (base64url)** (text): uncompressed P-256 point from subscription.keys.p256dh
- **Subscription auth secret (base64url)** (text): 16-byte secret from subscription.keys.auth
- **Receiver private key (base64url, optional — enables round-trip)** (text): user-agent P-256 scalar, only if you own the subscription keys
- **App-server ephemeral private key (base64url)** (text): 32-byte P-256 scalar; generate fresh per send in production
- **Salt (base64url, 16 bytes)** (text): random 16 bytes per message in production
- **Padding bytes** (number)
- **TTL seconds (RFC 8030)** (number)
- **Urgency (RFC 8030)** (select)
- **Topic (RFC 8030, optional)** (text): coalescing key, e.g. new-message
- **Push service host** (text)
- **Endpoint path** (text)
- **Build VAPID Authorization header (RFC 8292)** (checkbox)
- **VAPID sub (contact)** (text)
- **VAPID aud (push service origin)** (text)
- **VAPID exp (unix seconds)** (number)
- **VAPID signing private key (base64url)** (text): P-256 scalar, MUST differ from the encryption key

## 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

- Derives 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.
- Computes 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).
- Generates the ES256 VAPID Authorization JWT with audience, expiration, and subject claims, formatting the full HTTP/2 request with RFC 8030 headers (TTL, Urgency, Topic).
- Outputs 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.

## Frequently asked questions

### 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.

### 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.

## Related tools

- [Data URI Generator](https://elysiatools.com/en/tools/data-uri-generator): Convert files into Data URIs (Base64 or percent-encoded) for inlining images, fonts, and assets directly into HTML, CSS, or Markdown
- [Hash Algorithm Comparator](https://elysiatools.com/en/tools/hash-algorithm-comparator): Hash the same input with MD5, SHA-1, SHA-256, SHA-512, BLAKE2b, and BLAKE3 at the same time and compare them side by side: output length, hex/Base64 digest, security status (broken / modern), and a relative speed benchmark. Great for teaching, choosing a hashing algorithm, or sanity-checking checksums.
- [RSA Encrypt / Decrypt](https://elysiatools.com/en/tools/rsa-encrypt-decrypt): Encrypt text with an RSA public key or decrypt ciphertext with the matching private key, using OAEP padding (SHA-1 or SHA-256). Handles long messages by chunking. Keys and data stay local. PKCS#1 v1.5 is intentionally not offered (Node disables it for decryption due to Bleichenbacher attacks).
- [OpenTelemetry W3C traceparent / tracestate / baggage + OTLP Header Propagation Validator](https://elysiatools.com/en/tools/opentelemetry-w3c-traceparent-tracestate-baggage-and-otlp-protobuf-headers-propagation-validator): Validate W3C Trace Context propagation headers end to end: traceparent (version / 16-byte trace-id / 8-byte parent-id / trace-flags), tracestate (≤32 list members, tenant keys), baggage (percent-encoded values + opaque properties), OTLP export Content-Type, the gRPC grpc-trace-context-bin 25-byte binary context — plus a two-header correlation round-trip with a random child span-id collision check.
- [Base64 Converter](https://elysiatools.com/en/tools/base64-converter): Encode and decode data to/from Base64 format with URL-safe options
- [PCIe Link Training LTSSM & Lane Margining Eye Decoder](https://elysiatools.com/en/tools/pcie-link-training-linkstate-and-lane-margining-eye-decode): Decode a PCIe link training log (LTSSM state sequence plus TS1/TS2 ordered sets) into the full Gen1-Gen6 state timeline: negotiated speed and width, rate identifier bits, lane reversal, polarity inversion, equalization phases and Detect/Recovery restart diagnostics. Also grades a lane margining report (pcilmr CSV or key=value) against the PCIe Base Spec Rev 5.0 §8.4.2 eye minimums per generation and renders a per-lane eye-margin heatmap SVG.
- [PKCE Code Verifier & Challenge Generator](https://elysiatools.com/en/tools/pkce-code-verifier-generator): Generate, validate and verify OAuth2 / OIDC PKCE (RFC 7636) code_verifier and S256 code_challenge pairs. Three modes: (1) generate a fresh verifier + challenge from cryptographically secure random bytes at 256/384/512/768-bit entropy, (2) audit a verifier you already have against the RFC — length (43–128), charset \[A-Za-z0-9-._~\] and ≥256-bit entropy, and (3) verify a verifier/challenge pair by recomputing BASE64URL(SHA256(verifier)). Optionally build the full authorization-request URL and token-exchange body. Complements the generic nonce-generator (which only emits a verifier+challenge pair) with RFC-compliance auditing and pair verification.
- [Podcast Chapter Marker Builder](https://elysiatools.com/en/tools/podcast-chapter-marker-builder): Build every podcast chapter format from one timecoded list: Podcasting 2.0 JSON + RSS tag, ID3v2.4 CHAP+CTOC burned into an MP3, Vorbis comments, mp4chaps, YouTube timestamps and SRT, with a per-player support matrix.

## Samples

- [Web Image Processing Python Samples](https://elysiatools.com/en/samples/web-image-processing-python): Web Python image processing examples using PIL/Pillow including reading, saving, resizing, and format conversion
- [Web Image Processing Rust Samples](https://elysiatools.com/en/samples/web-image-processing-rust): Web Rust image processing examples including image read/save, scaling, and format conversion
- [Web Image Processing TypeScript Samples](https://elysiatools.com/en/samples/web-image-processing-typescript): Web TypeScript image processing examples including image read/save, scaling, and format conversion
- [Web File Operations Go Samples](https://elysiatools.com/en/samples/web-file-operations-go): Web Go file operations examples including text file read/write, file copy/move, directory traversal, and file validation