A newsletter signup is an email field and a button, and it converts on the sentence next to it. "Subscribe to our newsletter" asks a stranger for their address in exchange for an unspecified amount of future mail, which is why the least-designed part of this block is the part that decides its result.
12 public components on 21st have "newsletter" in the name.
The placements
In the footer. The lowest-intent position and the highest absolute volume, because it appears on every page. Ruixen Gradient Footer by Ruixen UI ships the pattern inside the footer, which the footer guide covers.
As a section. Newsletter Section by originui is the dedicated block, and Newsletter Signup by preetsuthar17 is the form with validation and a success state.
As a dialog. Newsletter Dialog by Ravi Katiyar is the interruption. It converts better than a footer field and it costs goodwill, and the rule from the dialog guide applies hardest here: a modal that appears before the reader has read anything is the pattern everyone has learned to close without looking.
The sentence that does the work
Three things, in about fifteen words.
What is in it. Not "updates" - what you actually write about. "One deep-dive on interface engineering, most Fridays" is a promise a reader can evaluate.
How often. Frequency is the reader's main fear, and stating it removes the fear.
Where they can see one. A link to the last issue is the single highest-converting element in this block, because it turns a promise into a sample.
The mechanics
A real label. The inputs guide makes the case in general; here the field is often placeholder-only, which fails for anyone interrupted mid-typing and for anyone using a screen reader.
type="email" and autocomplete="email". Two attributes that decide whether a phone offers the address in one tap.
A visible success state. Replace the form with a confirmation rather than clearing the field, which is indistinguishable from a failure.
Double opt-in if you will send marketing. It costs some signups and protects your sending reputation, which matters more the moment the list has thousands of addresses, as the waitlist guide argues.
A honeypot and a rate limit. An open form collects bot addresses that wreck deliverability on the first real send.
The thing not to do
Do not couple the signup to the content. A blog post that hides its second half behind an email field trades one reader for one address, and the reader you lost was the one most likely to subscribe later on their own terms.
The same goes for consent: a checkbox pre-ticked to also receive product mail is a consent problem, per the cookie banner guide, not a growth tactic.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| An email platform's embedded form | The list living where you send from | Their markup and styling constraints |
| shadcn/ui | Input, Button and Form underneath your own block | You wire the delivery |
| A link to the archive | Converting better than any field styling | Requires having written something |
| 21st | Sections, footers and dialog variants | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue.
Frequently asked
- What should a newsletter signup say?
- What is actually in it rather than the word updates, how often it arrives, and a link to the last issue. That link is the highest-converting element in the block, because it turns a promise about future mail into a sample the reader can judge.
- Where should the signup go?
- The footer gets the most impressions and the lowest intent; a dedicated section converts better in context; a dialog converts better still and costs goodwill, especially before the reader has read anything, which is the interstitial pattern everyone has learned to close.
- What does the form itself need?
- A real label rather than a placeholder, type="email" with autocomplete="email" so a phone offers the address in one tap, a visible success state that replaces the form, double opt-in if you will send marketing, and a honeypot plus rate limit so bots do not wreck deliverability.
- Should content be gated behind a signup?
- No. A post that hides its second half behind an email field trades one reader for one address, and the reader you lost was the one most likely to subscribe later on their own terms. Pre-ticked consent checkboxes are a consent problem rather than a growth tactic.