Last updated: 2026-09-04

Push Notification Character Limits - iOS & Android Guide

Push notifications compete for attention in a crowded notification tray. Understanding platform-specific character limits and designing text for maximum impact within those constraints is essential for engagement. These limits stem not only from UI design choices but also from the technical constraints of APNs (Apple Push Notification service) and FCM (Firebase Cloud Messaging) payload sizes.

APNs and FCM Payload Limits - The Technical Root Cause

The fundamental reason push notification text is limited comes down to payload size caps. With the current HTTP/2-based APNs provider API, the maximum payload is 4,096 bytes (4 KB). The older binary interface allowed only 2 KB, and Apple discontinued that legacy connection in March 2021, so the 4 KB figure is the one that applies to apps shipping today. FCM notification messages share the same 4,096-byte ceiling, while data messages are capped at 4,000 bytes.

The payload carries more than just the title and body. Sound settings, badge counts, and custom data (deep-link URLs, campaign IDs, etc.) all consume space within the same JSON-encoded envelope. Because UTF-8 encodes multibyte characters at 2–4 bytes each, the effective character count varies by language. After subtracting metadata and custom fields, the actual text budget is typically less than half the raw payload limit.

Platform Character Limits

Beyond the payload ceiling, each OS imposes its own display constraints. The table below summarizes visible character limits across major platforms.

One caveat before you read the numbers. The official documentation from Apple and Google describes how much text is shown in terms of lines, not characters: the Android developer guide, for example, states only that body text in the collapsed view is truncated to fit a single line, and gives no character count at all. The figures below are practical reference points as of August 2026, assuming the default system font size, and some of the rows cover cases the vendors never document. Read them as relative relationships between display frames, not as absolute thresholds you can rely on: a lock screen holds several times more body text than a banner, and an expanded Android notification holds several times more than a collapsed one. That ordering is stable even though the exact counts shift with font size, language, and OS version.

A key detail: even on the same OS, display context matters enormously. An iOS banner shows roughly 80 characters of body text before vanishing, while the lock screen renders about 178 characters across four lines. The Notification Center lets users long-press to reveal the full payload text.

Allocating Characters by Notification Type

Rather than looking for a single ideal length, it helps to sort your notifications into two kinds and budget characters differently for each.

Notifications that confirm something. A payment went through, a delivery arrived, a message came in. Here the reader wants to close the loop and move on, so the body only has to answer "what happened, to what, and how much." A line like "Payment received: $500.00" is complete. Adding a marketing phrase to the same slot forces the important part further to the right, where the collapsed view may cut it off. For this type, spend the fewest characters you can and put the concrete value (amount, item name, sender) as early as possible.

Notifications that ask the reader to go somewhere. A sale is starting, an article was published, an event is open. Nothing has happened to the reader yet, so the text has to supply a reason to tap: what is on the other side, and why now. That needs more room than a confirmation does, and the deadline or the specific figure is usually the part worth spending characters on.

The practical failure mode is running both kinds through one template. Once a shared prefix like your app name or a fixed "Notice:" label sits in front of every title, confirmations lose the space they need for the value, and promotional notifications lose the space they need for the reason - and neither problem is visible in a spreadsheet of copy. Check each type in the display frame it actually appears in, with the longest realistic values substituted in.

As with business email, brevity is essential, but push notifications demand even more compression. With collapsed views showing only 1–2 lines, the first 40 characters of the body must carry the core message.

Why Character Limits Differ Between Platforms

iOS banner notifications are limited to two lines by design. A notification is an interruption of whatever the user was doing, so the display area is deliberately kept small: it is meant to be taken in without stopping, not read. Starting with iOS 16, lock screen notifications were moved to the bottom of the screen to prioritize wallpaper visibility, further constraining the display area.

Android's expandable view is in line with progressive disclosure, a general UI idea: show the minimum first, and let anyone who wants more ask for it. The collapsed state shows a single-line summary; if the user is interested, they can expand to read the full message. Since Android 13, notification permission has shifted to an opt-in model requiring explicit user consent via the POST_NOTIFICATIONS permission - mirroring iOS behavior. This change has lowered Android opt-in rates, making it even more important to deliver high-quality notifications to the users who do grant permission.

Rich Notification Character Limits and Design Considerations

Rich notifications - using iOS Notification Content Extensions and Android's BigPictureStyle / BigTextStyle - support images, action buttons, and carousels. However, they introduce text constraints that differ from plain-text notifications.

• Image attachments shrink the text area: The image and the text share one notification, so attaching a picture leaves less room for the body than the same notification would have without it. How much less depends on the OS version and the display frame, and it is not a figure either vendor publishes - check it on a device rather than assuming a ratio. Write the copy so it still makes sense when the image never appears: attachments are fetched over the network after delivery, and a slow or failed fetch leaves the reader with text only
• Action button labels: Android's developer documentation states that a notification can offer up to three action buttons. iOS also shows only a small number, so in either case design for a handful of choices at most, not a menu. Neither platform publishes a character limit for the labels themselves, but the buttons sit side by side in a narrow strip, so long labels get truncated in practice. Five to eight characters is a safe working target (e.g., "Buy Now," "Details")
• Payload impact: Image URLs and action button definitions consume payload space, reducing the budget available for text. Images are typically delivered via URL reference (using APNs mutable-content + Notification Service Extension) rather than embedded in the payload itself

Wearable Display Constraints - The Overlooked Edge Case

Apple Watch and Wear OS devices impose even tighter character limits than smartphones. On Apple Watch, the Short Look (displayed for a few seconds upon receiving a notification) shows only the app name and a portion of the title - the body is invisible until the user transitions to the Long Look. Even in Long Look, the small screen causes line wrapping at around 60 characters.

On Wear OS, notifications appear as cards that users can scroll through, but the initial view shows only the title and roughly the first 30 characters of the body. Since wearable users often check notifications while moving or exercising, the title alone must convey the essential information. For wearable-optimized notifications, keep titles under 20 characters and place the core message within the first 30 characters of the body.

Web Push Notification Constraints

Web push notifications vary significantly across browser and OS combinations. Chrome, Firefox, and Safari each render different character counts and visual styles, so designing for the most restrictive environment is the safest approach.

Safari added Web Push support starting with macOS Ventura, but on iOS, Web Push is only available from iOS 16.4 onward and only for PWAs (apps added to the home screen). Standard browser tabs cannot send Web Push on iOS, which limits reach to iOS users.

As a general rule, titles under 30 characters and bodies under 80 characters will display without truncation across major browser-OS combinations. An icon or badge image is worth setting for a more practical reason than decoration: web push arrives without the app icon that an installed app gets for free, so unless you supply one, the notification is identified only by the browser or the site name. Making the sender obvious at a glance is what the image buys you.

A/B Test Design for Push Notifications

A/B testing push notifications requires a different approach than email A/B tests. Notifications cannot be recalled once sent, and user reactions concentrate within minutes, so test design must account for these constraints.

• Isolate one variable per test: If you are testing title length, keep the body, send time, and image constant. Changing multiple elements simultaneously makes it impossible to attribute results to any single factor
• Ensure adequate sample size: Each variant needs at least 1,000–2,000 users for statistically significant results. Apps with smaller user bases should accumulate data across multiple test cycles
• Control for time of day: Send both variants at the same time. Morning and evening tap rates differ dramatically, so staggered sends will skew results
• Track beyond tap rate: Measure notification-driven conversion rate, in-app session duration, and opt-out rate alongside tap rate. A high tap rate paired with rising opt-outs signals long-term damage

Personalized Notification Character Strategy

Personalized notifications insert dynamic data - user names, product names, or account balances - into templates, which means the fixed-text portion must be sized to accommodate variable-length insertions. For example, a template like "{username}, you left items in your cart" will vary in total length depending on the username.

Most usernames fit in well under twenty characters, but a few will run past that, and a display name someone set themselves can be longer still. When designing templates, keep the fixed portion under 25 characters and reserve at least 15 characters for the dynamic segment. This keeps the title visible without truncation even for the longer names.

The part worth planning for is what the notification looks like when the insertion fails. Personalization draws on data that is not always there: the account may have no display name, the record may be missing, or the lookup may time out at send time. Decide the fallback text in advance ("you" or a neutral greeting) rather than letting a template emit a literal placeholder or a stray comma. Before a campaign goes out, view every personalized template twice on a real device: once with the longest value you expect, and once with the value empty. Those two cases catch nearly all of the broken copy that reaches users.

Preventing Notification Fatigue - Frequency and Character Count

Frequency and character count are correlated. When sending frequently (once a day or more), keep each notification ultra-short (titles under 15 characters, bodies under 30) to minimize cognitive load. When sending less often (1–2 times per week), slightly longer bodies (60–80 characters) with richer detail are acceptable without triggering fatigue.

Notification type also matters. Transactional notifications (order confirmations, shipping updates) are exempt from frequency caps because users expect them in real time. Promotional notifications, however, should be capped at 2–5 per week for most apps. Implementing a per-user frequency cap (a maximum number of sends within a rolling window) provides a systematic safeguard against notification fatigue.

iOS vs. Android Permission Rate Differences

The two platforms arrived at today's situation from opposite directions. iOS has required an explicit permission prompt for push notifications since the feature existed, so an iOS app has never been able to assume it can reach a user. Android, before Android 13, enabled notifications by default for every installed app. Android 13 introduced the POST_NOTIFICATIONS permission and moved to the same opt-in model, which means an Android app written against the older assumption now has to ask as well - and a portion of the audience it used to reach by default will say no.

For both platforms, the timing and wording of the request matter, and the reason is structural rather than a matter of persuasion: the OS shows its permission dialog only once. If the user declines it, the app cannot bring it back - the only remaining path is to send them into the system settings screen and hope they follow through. That is why the "pre-permission" pattern exists: show your own in-app screen first, explaining what the notifications will be for, and trigger the OS dialog only when the user has said yes to that. A refusal on your own screen costs nothing, because the one irreversible dialog has not been spent yet. It also argues for asking after the user has experienced some value (a first purchase, a saved favorite) rather than on first launch, when they have no basis for deciding.

Common Mistakes

• Sending notifications late at night: Notifications between 10 PM and 7 AM don't just disturb sleep; they directly lead to notification opt-outs and app uninstalls. Timezone-aware scheduling is essential. For globally distributed apps, this means detecting each user's local timezone and scheduling delivery accordingly
• Vague titles like "Update" or "Important": A title such as "Update" gives the reader nothing to decide with, so the cheapest response is to dismiss it. A title like "50% off until 6 PM today" does the deciding for them: the figure says what is on offer and the deadline says why the decision cannot wait. The gain comes from putting the concrete information in the one line that is always visible, not from the wording being livelier
• Blasting the same notification to all users: Unsegmented bulk sends are noise for irrelevant users. Segmenting by user attributes (purchase history, app usage frequency, region) and tailoring notification copy to each segment improves both tap rates and conversion rates
• Missing deep links: Opening the app's home screen after a notification tap is a UX failure. The notification has already told the reader what it is about, so landing them on the home screen asks them to find it again by hand - and every extra tap is another chance to give up before arriving. Linking straight to the relevant content (a product page, a campaign landing page, an order status screen) removes that search, which is the whole reason the tap converts more often

Pro Notification Techniques

• Use rich notifications where the image carries information: An image is worth attaching when it says something the text cannot - the actual product, the actual map, the actual photo someone sent. It is not worth attaching as decoration, because it costs payload space and a network fetch. Always design a text-only fallback: the attachment is downloaded after delivery, so a slow connection means some readers see the words and nothing else
• Optimize send time per user: Rather than sending to all users at the same time, infer each user's most active hours from their app usage patterns and schedule delivery individually. Resist the urge to adopt a "best time to send" borrowed from someone else's audience: the reliable source is your own delivery log, broken down by hour. Compare tap rates for the hours you have actually sent in, note the hours you have never tried, and let the pattern in your own data decide - it will differ by app, by segment, and by notification type
• Leverage notification channels for priority control: Android 8.0+ notification channels let you separate notification types (transactional, promotional, news) into distinct channels. Users can toggle channels independently, preventing important transactional alerts from being silenced alongside promotional messages

Conclusion

Push notification character limits are shaped by both APNs/FCM payload caps and each OS's UI design philosophy. Display constraints vary not only between iOS and Android but also across lock screens, banners, notification centers, and wearable devices. For cross-platform safety, keep titles under 20 characters and bodies under 40. Allocate those characters according to what the notification is for - a confirmation needs the value early and little else, while a notification that asks the reader to go somewhere needs room for the reason - then run A/B tests to refine the copy. When you personalize, decide the fallback text first and check each template with both the longest value and an empty one. Use Character Counter to verify your notification text fits before sending.