Newsletter Ad Sizes: The Complete 2026 Spec Guide

You don't notice newsletter ad sizes until a sponsor sends the wrong file and your clean issue turns into a mess in Gmail. I've had that happen with a banner that looked fine in Figma, then clipped in the inbox, then got forwarded back with a refund request. After you break a few placements, the lesson gets simple fast. In email, the ad size that matters is the one that survives the client, fits the canvas, and still leaves room for your editorial content.

Table of Contents

• The Send That Made Me Rewrite Every Ad Spec
• The Two Constraints That Decide Every Ad Dimension
  • The canvas comes first
  • The file budget is the real limiter
• Recommended Sizes for Every Newsletter Ad Slot
  • Header, mid-content, sidebar, and CTA strip
• Retina Displays, File Formats, and the 2x Rule
  • Designing at 2x without bloating the send
  • File formats that actually behave
• How Each Platform Handles Newsletter Ad Slots
  • beehiiv, Substack, Ghost, LetterBucket, and Kit
• Testing Ad Sizes Without Breaking Deliverability
  • Change one thing at a time
  • The small test that changed my header rule
• The Sponsor Creative That Broke and How I Fixed It
  • Open Graph size is not newsletter size
• Quick Reference Specs You Can Copy Today
  • The short version I keep open while building
• How the Right Specs Help You Sell Sponsorships
  • Clean specs reduce friction, and friction costs money

The Send That Made Me Rewrite Every Ad Spec

I still remember the send that made me stop treating newsletter ad sizes like web banners with a different label. A sponsor handed me a 728×90 creative, which is a perfectly normal leaderboard size on the web, then I dropped it into a newsletter that was built around a 600 px email canvas. It looked squeezed, the spacing collapsed in Outlook, and the whole thing felt wrong before I even checked the render.

That was the first time I stopped asking, “What's the standard ad size?” and started asking, “What does this specific inbox tolerate?” The answer changed depending on the client, the template width, and how close I was to Gmail's clipping limit. I've broken enough placements now to know that a sponsor creative can be technically correct and still be a bad fit for email.

Practical rule: if the ad was designed for a web page, I assume it needs resizing before it ever touches my newsletter.

The other mistake I made early on was treating the ad as a separate object instead of part of the email body. In a newsletter, the ad competes with copy, images, and the rest of the message for space and weight. That's why newsletter ad sizes are mostly about fit and file budget, not just pixel counts.

I now check every sponsor asset against the canvas first, then against the total email weight, then against the client quirks. That order matters. If I reverse it, I end up redesigning in production.

The Two Constraints That Decide Every Ad Dimension

The canvas comes first

The long-running baseline for email and newsletter templates is 600 px wide, because it renders reliably across desktop and mobile clients, and many design guides still recommend staying close to that width, with safe ranges around 600–650 px. I treat that as the operating window, not a preference. If I push too far wider, I'm asking the email client to do extra work for no real gain.

A lot of ad problems come from sizing a placement as if it were independent of the newsletter. It isn't. In practice, ad units need to be sized as a share of the email canvas, which is why a sponsor's web banner often needs cropping, reflow, or a new composition before it can live inside the email.

Practical rule: if the template is built at 600 px, I design the ad for 600 px too, then adjust height and file weight from there.

The file budget is the real limiter

The second constraint is Gmail clipping. Keeping the total email under about 100–102 KB helps avoid clipping, and that ceiling matters more than people expect when the newsletter includes multiple images. I also keep an eye on content blocks around 200–300 px high, because they're easier to scan and they fit common inbox previews better than tall blocks.

The file math is usually tighter than the sponsor expects. If my plain-text copy, logo, and editorial images already consume most of the budget, the ad gets whatever remains, not whatever the brand wants. That's why I think in leftover bytes, not in abstract “creative space.”

The basic process is simple. First, estimate the newsletter's existing weight. Second, reserve room for the editorial images and logo. Third, check whether the sponsor creative fits inside what's left. If it doesn't, I resize or compress before the send, because fixing clipping after launch is always uglier than preventing it.

Recommended Sizes for Every Newsletter Ad Slot

Header, mid-content, sidebar, and CTA strip

I use different sizes depending on where the ad sits in the email, because placement changes both attention and tolerance. A header slot has to carry the visual load quickly, while a mid-content block can do more work with supporting copy. That's why there's no single universal size.

The mid-content rectangle is the one I use most often when I want a sponsor message to feel like part of the issue instead of an interruption. It behaves like the email-native version of a 300×250 display unit, which is why it usually outperforms tiny banner thinking in my stack. For direct response offers, I'd rather give the sponsor a bit more height than cram the pitch into a thin strip.

For header placements, I keep the creative lean and accept that the banner is there to anchor the issue, not to do all the persuading. For sponsored blocks, I like a little text alongside the image because it gives the offer context without forcing a reader to decode the visual alone.

I stay conservative on weight too. Industry guides commonly point to around 10–15% of the remaining message-size budget per image when a newsletter carries multiple images, and that's usually where the creative starts to get me into trouble if the sponsor ignores compression. The safest move is to treat the ad as one component of the send, not a separate file with its own rules. MailADX's newsletter creative specs lays out the common placement sizes and the standard display units I see most often in buying conversations.

Retina Displays, File Formats, and the 2x Rule

Designing at 2x without bloating the send

When I build a sponsor creative for newsletter work, I design it at 2x and export it at 1x. So a 600×250 placement starts as a 1200×500 artboard, then gets compressed down for the actual send. That keeps text sharper on high-density screens without forcing me to publish a giant file.

The trade-off is obvious. A larger source file is easier to overdo, so I've got to compress hard before it goes out. I'd rather make that decision in export than discover blurry type after the email is already in inboxes.

File formats that actually behave

For logos and ad units with text, I usually prefer PNG because the edges stay crisp. For photographic creatives, JPG is usually safer because compression hides better and the file size stays manageable. I'm cautious with WebP in sponsored placements because support across email clients still feels patchy enough that I don't trust it for anything important.

I also keep the creative readable even if images are muted. That means alt text, plus a short line of copy in the email body. In practice, I write 1 to 2 sentences around the sponsor asset, then give the ad a compact headline that reads fast, almost like a subject line. That little bit of context is what makes the ad work when the image doesn't fully load.

If I need a refresher while building the creative, I keep this internal graphics-in-emails reference open for a quick check on sizing and image handling. It's useful, but it doesn't remove the need to test in the actual email client, which is where most of the annoying bugs show up.

The ceiling I watch most closely is the per-image budget most ESPs warn about, which sits around 200 KB in many workflows. I try to stay comfortably under that for sponsor art, because the moment a creative lands near the top of that range, the rest of the email starts to feel cramped.

How Each Platform Handles Newsletter Ad Slots

beehiiv, Substack, Ghost, LetterBucket, and Kit

beehiiv is the most straightforward platform I've used for sponsor inventory because its ad handling is built into the product. When I tested the Monetization > Ads area, the UI made it easy to see placements and drop in sponsored copy, and the default creative conversations kept circling back to standard sizes like 300×250. It's convenient, but the downside is that you're living inside beehiiv's way of doing things, which can feel rigid if your brand wants a custom layout.

Substack is the one I stopped using for sponsor banners because I kept running into custom HTML workarounds that looked fine in the editor and then broke in Outlook. That mismatch is the whole problem with forcing display-style ads into a newsletter platform that wasn't really built for them. The upside is simplicity for publishing. The downside is that ad inventory feels improvised.

Ghost gives me the most flexibility because I can inject sponsored content through template tags and self-hosted layouts. That freedom is useful when I want a placement to match a specific issue design, but it also means I own more of the upkeep. If something breaks, I'm the one who has to trace it.

LetterBucket is part of my stack now, and I use it for some of my own newsletters because it keeps the workflow fairly clean. The weak spot is reporting. I can get the slot in place, but the ad performance view still feels thinner than I'd like, so I usually supplement it with my own tracking and seed checks. It's practical, just not as polished as I want yet.

Kit, formerly ConvertKit, is the platform I'd pick when I want a straightforward sponsor workflow with a recognizable placement standard. I've seen it work best when the ask is simple and the ad slot needs to stay close to a 600×150 style block instead of a more elaborate native build.

If I were choosing for a paid newsletter with frequent sponsor changes, I'd pick beehiiv. For maximum layout control, I'd use Ghost. For a lightweight personal newsletter, I'd keep Substack only if I wasn't planning to sell display-style ads at all.

If you're comparing stacks, my broader notes on newsletter software choices are more useful than vendor marketing pages because they reflect the actual setup friction, not just the feature list. I'd still avoid treating any platform as magic. The ad still has to fit the email.

Testing Ad Sizes Without Breaking Deliverability

Change one thing at a time

I test ad sizes by changing one variable only. Banner height, image weight, or placement. Never all three at once. If I want to know whether a taller header works better than a shorter one, I hold everything else fixed and split the send by subscriber ID hash, not by opens, so the test reaches the full list instead of just the people who already opened past campaigns.

I watch render rate, click-to-open, and revenue per send. Raw clicks are too noisy for this kind of work because a bigger banner can win attention without converting better. I care more about whether the placement earns its keep inside the issue.

The small test that changed my header rule

One of my cleaner tests compared a 600×150 header against a 600×100 header. The taller version moved click-to-open from 2.1% to 2.6%, but the sample was small and the result held for only two sends before fading. I kept the taller format in rotation for a while, but I didn't treat it as a permanent law.

That's the part people miss. A test result can be real and still not generalize. I've had enough false wins to know that a layout change can look great for a week, then normalize once the novelty wears off.

Practical rule: if a size change improves clicks but hurts readability or pushes the issue closer to clipping, I drop it.

The other thing I check is whether the ad still feels natural in the email preview. A good newsletter ad size doesn't just fit the artboard. It survives the first glance on mobile, the Inbox preview line, and the client quirks that break aggressive layouts.

The Sponsor Creative That Broke and How I Fixed It

Open Graph size is not newsletter size

The worst creative I ever received was a sponsor asset at 1200×628, which is fine for Open Graph and awful for a normal newsletter slot. It came in at 480 KB, and the email clipped at the ad in Gmail. The sponsor's first reaction was to ask for a refund, which is understandable if you don't know how email clipping works.

I fixed it in one short session. I resized the image to 600×314, recompressed it to under 150 KB, added alt text, and swapped the sponsor's PNG logo for a JPG fallback so Outlook wouldn't choke on it. Then I sent it to a seed list before the next scheduled send and checked the render across the clients I care about most.

The whole thing took about 20 minutes, which is still less time than the back-and-forth I'd have spent if I'd tried to argue with the original file. The following week, the click rate recovered. Not because the offer changed, but because the placement finally fit the email.

Here's the checklist I use when a sponsor asset arrives:

• Check the dimensions first. If it was built for a web preview, it usually needs a new crop.
• Check the file weight second. If it's anywhere near the clipping line, compress before anything else.
• Check the text in the image. If the type is small, 2x design becomes essential.
• Check the fallback behavior. If Outlook or another client strips the creative badly, I change format before launch.
• Check the seed render. I never trust a sponsor file until I've seen it in at least one real inbox.

That sequence saves more time than any fancy design rule. It also keeps the sponsor from blaming the platform when the actual problem is the file they sent.

Quick Reference Specs You Can Copy Today

The short version I keep open while building

My pre-send checklist is shorter than many assume:

• Keep the canvas near 600 px.
• Keep each image under 200 KB when possible.
• Keep the total email under the Gmail clipping threshold.
• Add alt text every time.
• Save the source file at 2x before export.

The three pushbacks I hear most from sponsors are predictable. Wrong dimensions, oversized file, missing alt text. My answer is always the same, resize it, compress it, and fix the fallback before I schedule the send.

If you want a working spec sheet instead of rebuilding this from scratch, I keep my own templates in the format I use for production exports, which is easiest to manage when the design source and the email-ready file are clearly separated.

How the Right Specs Help You Sell Sponsorships

Clean specs reduce friction, and friction costs money

A clear ad spec sheet does more than make the email render. It saves the sponsor a round of revisions, and that makes the placement easier to sell. In my experience, buyers are happier paying for a slot that comes with exact pixel dimensions, file-weight limits, and format guidance than paying for one that turns into a last-minute design fire drill.

A basic media kit should include subscriber count, open rate, click rate, and audience demographics, and newsletter ad pricing is usually framed as CPM, CPC, or flat-rate. That structure is common in newsletter sponsorship work because it gives the buyer a concrete way to compare options and makes the publisher look organized. AdMailr's newsletter ads guide describes that media-kit model clearly, and it matches the way I've sold placements in practice.

When a sponsor asks what it costs, I lead with the placement and the audience fit, not the math formula. If they press for a number basis, I'll explain whether I'm pricing the slot on CPM, CPC, or a flat-rate deal, but I don't open with the model because most buyers care more about where the ad appears than how I priced it. I also don't love relying on CPM alone for small lists, because it can push you into pretending volume matters more than fit.

If I want a lightweight system for packaging those offers, I'll sometimes compare what I'm doing against my own notes on newsletter ad rates so I'm not underpricing the premium placements. The more exact the specs, the easier it is to defend the price. That's the part most creators miss. Sponsorship sales don't start with the invoice, they start with an ad creative that doesn't need rescuing.

If you're building or revising your sponsorship package now, audit your current newsletter against the 600 px canvas rule, trim any asset that's creeping toward Gmail clipping, and rewrite your spec sheet before the next sponsor asks for a banner. Then send yourself a test issue, open it in Gmail, Outlook, and mobile, and fix the thing that breaks before a sponsor finds it first.