What the Mobile Push Payload Builder does
This builder writes and checks the JSON that native mobile push services expect: the payload and headers for Apple Push Notification service (APNs) and the request body for Firebase Cloud Messaging's HTTP v1 API. It checks required keys, the 4 KB size limits, priority, collapse and expiry fields, and the mistakes that make a push fail silently - and it never sends anything or asks for a key or token.
It is not a web push tester. The site's Push Notification Tester sends test notifications to a browser through the Web Push protocol; this page is for iOS and Android apps, where the payload goes to Apple or Google from your own server.
How to use it
- Write the title and body, and any custom data as key=value lines - an order ID or a deep link, for instance.
- Choose a visible alert or a silent background update. Background pushes carry no title or sound, use apns-priority 5, and wake the app to fetch new data.
- Set a collapse ID if a newer notification should replace an older one, such as a live score, and how long the services should keep it for an offline device.
- Adjust the Apple and Firebase options, then read the checks under each payload. Fix anything marked as a problem.
- Copy the JSON, download both payloads, or copy the curl templates. They use shell variables such as $APNS_JWT and $ACCESS_TOKEN that you set on your own machine.
Reading the results
Sizes are measured as compact UTF-8 JSON, which is how APNs counts its 4,096-byte limit (5,120 for VoIP). For FCM the figure is an estimate of the notification and data parts; Google measures the stored payload, which is close but not identical.
Problems are rule breaks that make APNs or FCM reject the request or drop the notification: a missing aps dictionary, a non-string FCM data value, a background push at priority 10, a TTL over 28 days. Warnings are likely mistakes; notes explain what a field will do.
With the apns block included, iOS devices reached through FCM get the same priority, collapse ID and alert as a direct APNs push, instead of FCM's defaults.
Worked example: an order-shipped notification
The order example has the title "Your order has shipped", a one-sentence body, an order ID and a deep link, a badge of 1 and the collapse ID order-1042.
The APNs payload is 208 bytes of the 4,096 allowed, with the order ID and deep link beside the aps dictionary where Apple expects custom keys. The headers set apns-push-type alert, priority 10, the collapse ID, and an expiration 24 hours from now, because the offline time was set to 86,400 seconds.
The FCM body targets a device-token placeholder, sends the data values as strings, sets android.priority HIGH, a TTL of "86400s" and collapse_key order-1042. Its notification and data parts come to about 167 bytes.
Collapse, priority and expiry in one place
The three fields that decide what happens to a notification in transit have different names on each service. Apple uses the apns-collapse-id, apns-priority and apns-expiration headers; FCM uses android.collapse_key, android.priority and android.ttl, and passes Apple's headers through in the apns block. The builder fills all of them from one set of inputs, so an update that should replace the previous one does so on both platforms.
Expiry is easy to get backwards. APNs wants an absolute UNIX time; FCM wants a relative duration such as "3600s". Zero means the same on both: try once, then discard.
Limitations: what the result does not prove
- It validates structure and documented rules. It cannot tell whether a device token, bundle ID, topic subscription or Firebase project is real - only a send from your server can.
- Delivery is never guaranteed. Apple and Google throttle background and low-priority pushes, and devices in low-power modes may defer them however the payload is written.
- Rich content such as images needs app-side code (a notification service extension on iOS, a channel and handler on Android); the payload only carries the pointer.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- Apple Developer - Generating a remote notification (APNs payload) - checked 19 Sep 2026
- Firebase - FCM HTTP v1 message resource - checked 19 Sep 2026
- Apple Developer - Sending notification requests to APNs
- Apple Developer - Pushing background updates to your app
- Firebase - Set message priority, lifespan and collapsibility
Frequently asked questions
What is the maximum APNs payload size?
4 KB (4,096 bytes) for regular remote notifications and 5 KB (5,120 bytes) for VoIP notifications, measured on the JSON payload. APNs rejects anything larger with PayloadTooLarge, so keep bulky data on your server and send an ID.
Why must FCM data values be strings?
The HTTP v1 API defines data as a map of string to string. Numbers, booleans and nested objects are rejected with INVALID_ARGUMENT. Send 42 as "42", and send structured data as a JSON string your app parses.
What priority should a silent push use?
Apple requires apns-priority 5 for background notifications with content-available set to 1 and no alert, sound or badge. Priority 10 is for alerts shown immediately. On Android, a data-only message can be NORMAL unless it must wake the device at once.
How does a collapse ID work?
When several notifications share a collapse ID, the newest replaces the earlier ones, both on the device and in the service's queue for an offline device. It suits things like a live score or an order status. Apple limits the ID to 64 bytes; FCM stores at most four different collapse keys per device at once.
Is my payload in the legacy FCM format?
If it uses to, registration_ids, time_to_live or a top-level priority, yes. Google shut down the legacy HTTP API in 2024; HTTP v1 wraps the message in a message object with token, topic or condition, and per-platform android and apns blocks. The checker flags legacy fields.
How is this different from the Push Notification Tester?
The Push Notification Tester sends test web push notifications to a browser using the Web Push protocol. This builder is for native iOS and Android apps: it composes and validates APNs and FCM payloads, sizes and delivery options, and it sends nothing.
Can I send a test notification from this page?
No, deliberately. Sending needs your Apple signing key or a Google service-account credential, which should never be pasted into a web page. Use the curl templates on your own machine with the credentials in environment variables.
Last reviewed by the A2Z.Tools team against the sources listed above.
