Cover the headline on any SaaS landing page. Read the subheadline by itself. Does it mean anything?
Most of the time, the answer is no. The subheadline restates the headline in different words, then stops. It looks like copy. It reads like copy. It does nothing a blank line wouldn't do.
The subheadline is the second line a visitor reads. It's seen by almost everyone who reads the headline. It's almost always wasted.
What the subheadline is actually for
The headline makes a claim. The subheadline bridges that claim to the proof below it.
Think about what a visitor is doing when they land on your page. They read the headline in 2 seconds. They decide if it sounds relevant. If it does, they need one more thing before they keep scrolling: a reason to believe the claim is true, or a clarification that the claim is meant for them specifically.
That's the subheadline's job. Not to repeat the headline with a synonym swap. Not to pack in the second and third value props that didn't fit in the headline. To answer the visitor's first question after reading the headline: "Okay, but is this actually for me, and does it actually work?"
Most subheadlines answer a different question: "How can I say the same thing one more time?"
The 4 things a subheadline can do
Pick one. Trying to do all 4 at once is how you end up with 40-word subheadlines that nobody reads.
Name the who. The headline made a broad claim. The subheadline narrows it to a specific audience. "For engineering teams shipping across 3+ time zones." "Built for solo founders, not enterprise." The visitor reads the headline and thinks "that sounds interesting." They read the subheadline and think "that's me." Now they're paying attention.
Name the mechanism. The headline promises an outcome. The subheadline briefly explains how. "By syncing your task data across Slack, Notion, and Jira automatically." "Without switching tools or writing custom SQL." The visitor understands what the product actually does, not just what it produces.
Handle the objection. Every bold headline has a "but wait" response in the visitor's head. The subheadline answers it. Headline: "Deploy your API in 3 minutes." Subheadline: "No infrastructure setup, no config files, no DevOps." The objection ("that sounds like it'd take days") is answered before the visitor fully forms it.
Add a specific proof point. Numbers anchor abstract claims. "Join 14,000 teams who've cut their reporting time by 60%." "Used by engineers at Stripe, Linear, and Figma." The claim in the headline is now backed by a number or a name the visitor recognizes. Suddenly the headline sounds credible, not aspirational.
What most subheadlines do instead
Here's a pattern I see across the majority of landing pages I audit:
Headline: "Ship better products, faster."
Subheadline: "The all-in-one platform for modern product teams to collaborate, build, and deliver with confidence."
The subheadline added words and subtracted meaning. "All-in-one" is on every SaaS page. "Modern product teams" describes everyone. "Collaborate, build, and deliver" is what every product tool says it does. "With confidence" is filler.
The visitor read both lines and now knows less than if they'd read just the headline.
The pattern: the subheadline is written to fill the space, not to do the job. Someone put copy there because the page template had a subheadline slot and empty slots feel wrong.
Before and after: 4 real examples
Project management tool
Before: "Everything your team needs to stay aligned and ship faster."
After: "For engineering teams of 10 to 50 who've outgrown Jira but can't afford a dedicated PM."
The before version says what every project management tool says. The after version names a specific situation, a specific company size, and a specific pain point (hating Jira, not ready for enterprise tooling). Someone in that situation reads the after version and thinks "that's exactly where we are."
Analytics platform
Before: "Powerful analytics that help you understand your data and grow your business."
After: "See which campaigns are actually making money. No SQL, no data team, no custom reports."
The before version is indistinguishable from any analytics tool's subheadline. The after version names the mechanism (no SQL), handles two objections (no data team, no custom reports), and makes the benefit specific (which campaigns make money, not "understand your data").
B2B email tool
Before: "The smarter way to reach your customers."
After: "14,000 B2B teams use it to book 30% more meetings from the same contact list."
The before version is meaningless. The after version has a proof point (14,000 teams), a specific outcome (30% more meetings), and a specific condition (same contact list, not a bigger list). A visitor reads it and has a concrete picture of what changes.
Developer tool
Before: "Build, test, and deploy with confidence."
After: "Trusted by engineering teams at Stripe, Vercel, and Loom. Deploys in under 4 minutes."
The before version is a tagline for every developer tool since 2010. The after version has two credibility signals (specific company names, specific time number) that anchor the headline's claim. A developer reads "Stripe uses this" and the bar clears immediately.
The cover test
Put your thumb over the headline. Read the subheadline by itself.
Does it mean something specific? Does it tell you who the product is for, what makes it work, or why you should believe it? Or does it sound like it could be the subheadline for any product in your category?
If you covered your headline and the subheadline still communicates something real, it's doing its job. If you covered your headline and the subheadline is a string of adjectives that could go on any landing page, you don't have a subheadline. You have a filler line.
Length and placement
One sentence. Two at the absolute most.
The subheadline lives in the hero section, below the headline, before the CTA. It's seen by everyone who reads the headline. That's a valuable slot. The content in it should earn the space by adding information, not filling pixels.
If you find yourself writing a 3-sentence subheadline, you're writing an intro paragraph, not a subheadline. Move the extra sentences down the page as supporting copy, or cut them. The subheadline's job is to close the gap between the claim and the belief. One clear, specific sentence does that better than three general ones.
Font size matters too. The subheadline should be visually lighter than the headline but still readable without squinting. On most landing pages that's somewhere between 18 and 24px at desktop. Small enough to sit below the headline hierarchically. Large enough to be read, not skimmed.
One thing to check before you ship
After you've written the subheadline, read the headline and the subheadline together as a unit. Ask: does the subheadline do something the headline didn't?
If yes, you're done. It earns its place.
If no, or if the subheadline could be lifted off the page and placed under a different headline with no loss of meaning, rewrite it. The test for a subheadline isn't "does it sound good?" It's "does it add something specific that makes the visitor more likely to keep reading?"
Any statistics cited in this post come from third‑party studies and industry reports conducted under their own methodologies. They are intended to be directional, not guarantees of performance. Real outcomes will depend on your specific market and execution.
Should the subheadline always follow the headline immediately?
Yes, in most hero section layouts. The visual hierarchy is: headline (large, bold) → subheadline (medium, regular weight) → CTA. The subheadline sits directly below the headline before any supporting content or CTA. This is the sequence most visitors expect and where the subheadline has the most impact. If your layout has the CTA between the headline and subheadline, you're asking visitors to act before you've finished making the case.
What if my headline is long? Do I still need a subheadline?
A long headline that's already specific (names the who, includes a number, handles an objection) may not need a subheadline at all. The subheadline exists to add what the headline couldn't fit. If the headline already does the job, a subheadline forces redundancy. A blank line is better than filler copy. That said, most long headlines are long because they're trying to say three things at once. The fix there is to cut the headline, not add a subheadline that patches it.
How do I know which of the 4 jobs to give the subheadline?
Read the headline and think about the first objection a skeptical visitor would have. If the headline is a big claim ("Triple your conversion rate"), the first objection is "prove it": use a proof point. If the headline is specific but broad ("Project management for remote teams"), the first objection is "which remote teams?": name the who. If the headline promises a result but not a mechanism ("Stop losing deals after the demo"), the objection is "how?": name the mechanism. The objection a visitor would voice tells you which job the subheadline needs to do.
Can the subheadline include a CTA?
No. The subheadline is copy. The CTA is a button. Mixing them blurs the visual hierarchy and reduces click-through on the actual CTA. The reader's eye should move: headline → subheadline → CTA. Putting action-asking copy in the subheadline breaks that path. If you want the subheadline to create urgency, do it with a specific number or social proof, not with language that mimics a button.
Should both a mobile and desktop subheadline be written?
Usually no. One version, written for the shorter screen. If your subheadline is 2 sentences, the second sentence often disappears above the fold on mobile. Write a single sentence that works on both. If there's a genuine reason to show more on desktop (a longer proof point, a second qualifier), use CSS to show/hide the additional sentence rather than writing two separate subheadlines. Consistent copy across breakpoints is easier to test and easier to maintain.
