Anyone who runs a website ends up asking the same question sooner or later: I get a few thousand visitors a day, most of them read one page and vanish. How do I get them to come back? There are two classic answers. The first is a newsletter: ask for an email address, add it to a list, write to it. The second, more recent, is web push notifications: the browser asks for permission, the reader says yes, and from then on you can reach them with a short message that pops up on their phone or computer.
There are plenty of comparisons of the two channels online, and nearly all of them are written by someone selling one of them. This one is too, since we build web push, so let's be upfront about it: there is no outright winner. They are different tools, built for different moments in your relationship with a reader. Below we compare them point by point, with no made-up industry numbers, and at the end we look at how to make them work together.
If you are starting from scratch and are not quite sure what a web push notification is, the introductory guide explains the mechanics in ten minutes.
Sign-up: one click versus a form
The most obvious difference is at the front door.
To join a newsletter, the reader types their email address into a form, often ticks a consent box, then goes to their inbox, finds the confirmation message and clicks the link. That is double opt-in: it makes sure the address exists and that its owner is the one who entered it. It is good practice, but it is a multi-step path, and at every step some people drop off.
To subscribe to push notifications, the reader sees the site's prompt, then the browser's request, and clicks "Allow". Done. They type nothing, hand over no personal details like a name or address, and never have to open another app.
That difference cuts both ways. On one hand, a push sign-up is much lighter, so more people tend to accept it. On the other, it is also a lighter commitment: someone who hands over their email has made an effort and is usually more invested. A newsletter subscriber and a push subscriber are not the same thing, and comparing them as if they were makes little sense.
What you actually own
Email has a clear advantage here, and it deserves to be said plainly.
An email list is portable. It is a list of addresses: you can export it, switch sending services, and carry it with you for years. An email address works on whatever device the reader uses, today and five years from now, as long as they keep it alive.
A push subscription is tied to a browser and a domain. A reader who allows notifications in Chrome on their phone is not subscribed in Firefox on their laptop at home. If they clear their browser data, get a new phone or uninstall the browser, that subscription stops working. And the permission belongs to that exact domain: if the site moves to a new address, the subscriptions do not follow.
There is some good news, though: the permission belongs to the domain, not to the platform you send with. If you ever switch push providers while staying on the same site, readers do not see the browser prompt again. How to handle your existing subscribers during the move depends on the situation, and the migration guide walks through the options.
Put simply: email is a relationship with a person, push is a relationship with a device. Both wear out over time, just in different ways. Emails stop working when inboxes get abandoned; pushes stop when browsers get replaced or wiped. That is why a serious push platform rechecks subscriptions and removes the ones that are no longer valid: on Natom you only pay for active subscribers, not for the ones that have stopped existing.
Immediacy: seconds versus hours
When a push goes out, it lands on the reader's screen within seconds. If the phone is off, it is delivered as soon as it comes back online, within a time window the sender chooses. It shows up on the lock screen too, right next to app messages.
An email reaches the inbox just as fast, but the reader sees it when they decide to check their mail. That might be ten minutes later, it might be that evening, it might be never. Plenty of people check their personal email at set times, or only when they are expecting something.
That changes everything about what kind of content fits. A story that matters right now, a deadline that closes today, a match result, a weather warning: those are push content. An analysis meant to be read over a quiet weekend loses nothing if it gets opened the next day.
Message length
A push is tiny: a title, a couple of lines of text, an image on some systems, a link. On a locked phone, often only the title shows, and not always all of it. It has exactly one job: to earn the click. All the actual content lives on the landing page. That is why the title matters so much, and why we wrote a whole piece on push titles people click.
An email can be as long as you like. It can hold a full editorial, ten links, images, a personal sign-off, a voice. It can be read start to finish without ever leaving the inbox. For some formats, like a writer's newsletter or a thoughtful weekly roundup, that is the whole point: the value is inside the message, not behind the click.
Filters: spam folders and tabs versus browser permission
Each channel has its own gatekeeper.
Email goes through spam filters and, in the most popular inboxes, automatic sorting into tabs or folders: primary, promotions, social, updates. A well-written newsletter that the reader actually wants can still land in a secondary tab they rarely open. Deliverability depends on your sending domain's reputation, your technical setup and how recipients behave. It is a craft of its own.
Push has no spam filter in the traditional sense: if the reader granted permission, the notification is shown. The gatekeeper here is the permission itself. The reader can revoke it in two clicks from the browser settings, and operating systems group or quiet notifications from sites that send too many. There are also real platform limits: on iPhone, for example, web push only works if the reader has added the site to their Home Screen (more on that in our guide to web push on iPhone).
In short: email risks going unseen, push risks being switched off if it gets annoying. Two different risks, both managed the same way, by respecting the reader.
Cost: paying per send or per subscriber
Pricing models vary a lot on both sides, so let's reason about the logic rather than the figures.
With email, cost usually grows with the number of contacts and the number of messages you send. If you write often to a large list, you feel it. On top of that there is the work: layout, writing, keeping an eye on deliverability.
With push, it depends on the platform. Some charge per send, others per subscriber. Natom charges by subscriber count, with unlimited pushes on every plan, including the free one up to 1,000 subscribers. Sending one more notification costs nothing: the real limit is your readers' patience, not your budget. If you want to dig into the cost side, there is a dedicated piece on what web push costs.
Either way, the biggest cost is not the subscription. It is the time of whoever writes the messages, and the value of the subscribers you lose by sending things nobody needed.
Privacy and GDPR: the general picture
A necessary disclaimer: this is not legal advice. The rules depend on the country, the kind of site and how you use the data, and for your specific situation it is worth talking to a privacy consultant.
With that said, a few general differences are visible.
With email you collect a direct piece of personal data: the address, often paired with a name. You need clear consent for marketing messages, an easy way to unsubscribe in every email, and careful handling of the list (where it is stored, who can access it, how long you keep it).
With push, consent comes through the browser permission, which the reader gives with an explicit action and can withdraw at any time. You do not collect a name or address, but you still collect a technical subscription identifier and some device information, which should be handled with care and mentioned in your privacy notice. Natom, for instance, stores the subscription token, browser, OS and device, the country, and the topics the reader picked; it does not track browsing and does no profiling.
For neither channel is the right question "is it compliant or not" in the abstract. The right question is "how am I using it". A consultant will answer that better than any blog post.
Where each one wins
Put the points above together and the best use cases almost sort themselves.
When push is the right call
- Breaking news. Something that just happened and will be worth half as much in three hours.
- Deadlines that are close. "Applications close tonight", "last hours of free shipping".
- New content on a site that publishes a lot. Every article becoming a notification, ideally only for people who chose that topic.
- Short daily fixtures. Morning headlines, an evening recap: one title, one link, two minutes.
- Readers who would never give you their email. Lots of casual visitors will not fill in a form, but they will click "Allow".
When email is the right call
- The in-depth newsletter. A piece written to be read in full, at leisure.
- The curated weekly roundup. Not ten links, but a selection with commentary.
- Personal and transactional messages. Orders, receipts, accounts, renewals: things readers want to find again in their archive.
- The long-term relationship. When you want to reach someone years from now, even after they have changed phones three times.
- Content readers keep. An email can be filed and searched; a notification, once dismissed, is gone.
Why use both
If it now looks like the two channels do different jobs, that is because they do. Asking "push or email?" is a bit like asking "phone call or letter?": it depends on what you need to say. The sites that bring the most readers back are often the ones using both, each for its own job, without letting them trip over each other.
There is one golden rule: never send the same message twice across the two channels. If a reader gets the same story as a push at 9:00 and as an email at 9:05, they got a duplicate, and duplicates are the fastest route to unsubscribing from one of the two.
Natom only does push notifications: it does not send email. For a newsletter you need a separate service, and the work lies in making the two flows coexist with a bit of planning.
An example for a publisher
Say a local news site publishes around fifteen articles a day.
- During the day, push. Important stories go out as notifications, each to the audience for its topic. The sports reader does not get the court reports, and vice versa. With the RSS feed in draft mode, every new article becomes a draft already routed to the right category, and the newsroom decides what to send and when (the full workflow is in the guide to push for publishers).
- Early morning, a recurring push. At 7:00, "5 stories to start your day", linking to the roundup page.
- Saturday, the email. A bylined newsletter covering the week's three big themes, explained properly, plus a note from the editor. No breaking news: push already handled that.
- The bridge between them. Inside the newsletter, an invitation to turn on notifications for real-time news; on the site, for existing push subscribers, an invitation to the Saturday newsletter.
That way the two channels do not compete: push carries the news, email carries the meaning.
An example for an online shop
Say a small ecommerce store selling homeware.
- Email for everything about the order. Confirmations, shipping updates, invoices: customers want those in their inbox, where they can find them later.
- Email for storytelling. Once a month, the story behind a product, a how-to guide, the new collection with big photos.
- Push for urgency. "Free shipping until Sunday", "the terracotta pots are back", "last hours of the sale": short messages with a reason to click right now. If the shop runs on WordPress with WooCommerce, products can be pushed straight from the editor, as covered in the guide to web push for WooCommerce.
- Separate audiences. People who subscribed from the textiles page get textile pushes, thanks to tags set by the site; people who picked nothing get the general announcements.
Same principle here too: each channel does the job it was built for.
Comparison table
| Aspect | Web push | |
|---|---|---|
| Sign-up | One click on the browser permission | Address, consent, often a confirmation link |
| Data collected | Technical identifier, device, country | Email address, often a name |
| Portability | Tied to browser and domain | Exportable list, works on any device |
| Time to be seen | Seconds, even on a locked screen | Whenever the reader opens their mail |
| Length | Title and two lines, content lives on the site | Unlimited, content can live in the message |
| Filters | Revocable permission, system grouping | Spam filters, automatic tabs and folders |
| Platform limits | On iPhone only with the site on the Home Screen | Nothing significant |
| Typical cost | Per send or per subscriber (on Natom per subscriber, unlimited pushes) | Usually by contacts and sending volume |
| Best use | Breaking news, deadlines, new content | In-depth pieces, roundups, personal messages |
Frequently asked questions
Can push notifications replace a newsletter? For some sites, yes; for many, no. If your value lies in fast updates (news, offers, new articles), push may be enough. If it lies in long-form writing, argument, or a personal connection with the author, a newsletter is hard to replace. In most cases it makes sense to keep both.
Which channel brings more readers back to the site? It depends on the content and the audience, and we would be wary of anyone giving a flat answer backed by generic percentages. Push is designed to drive clicks to the site, because the message is too short to stand on its own. An email can be read entirely in the inbox without a single visit. The honest way to find out is to measure on your own site: push clicks and CTR on one side, newsletter clicks on the other.
Can I import my email list into push notifications? No, and nobody genuinely can. A push subscription only comes from permission the reader grants in their own browser: an email address cannot be turned into a subscription. What you can do is invite your newsletter subscribers to turn on notifications with a link to your site.
Does Natom send email too? No. Natom is a web push notification platform only. For a newsletter you need a separate email service; the two can live on the same site without getting in each other's way.
Is push more privacy-friendly than email? It collects less direct personal data, since it asks for neither a name nor an address, but it is not data-free: there is a technical subscription identifier. Both channels need consent, a clear privacy notice and an easy way out. For your specific case, check with a privacy consultant.
How many pushes can I send without losing subscribers? There is no number that fits everyone: it depends on how useful and how targeted they are. A push the reader cares about is not a nuisance; ten they do not care about are. Letting readers choose their topics, through reader preferences, is the simplest way to send more while bothering people less.