Why Ad Unit Size Matters
Ad unit size isn’t just a monetization choice—it’s a layout decision that can either protect your reading experience or quietly break it. When a unit is too wide for a container, it can overflow the content column, trigger horizontal scrolling, compress your typography, or force awkward spacing. When a unit is technically “inside” the column but feels oversized, it can interrupt the natural rhythm of reading. That’s why strong ad systems start with sizing: you decide what can fit everywhere, then you build templates around those constraints.
This Ad Unit Size Guide is designed to work like a practical reference. It includes a size library (with common names and use cases), a fit checker (so you can quickly verify container widths), and an export feature (so your team can document a consistent set of units). If you’re building a publisher site, a tool site, or a content network, consistency is your friend: fewer surprises, fewer layout bugs, and a cleaner experience for readers.
Fixed Sizes vs Responsive Units
Fixed sizes are simple: 300×250 is always 300 pixels wide and 250 pixels tall. Fixed units work well when your containers are stable and your templates are predictable. Responsive units, on the other hand, adapt to the available width (and sometimes choose a height from a set of allowed options). Responsive can be safer on modern sites where the content column changes across categories, sidebars, and device breakpoints.
The catch is that responsive isn’t magic. You still need to understand your smallest container width. If a page template has a very narrow column (for example, on mobile with padding and UI elements), your unit must still fit without overflow. Think of responsive as a tool for flexibility, not a substitute for measurement. The best ad systems use both: fixed for predictable areas (like sidebars) and responsive for variable areas (like in-article placements on mixed templates).
Common Ad Placements and the Sizes That Usually Fit
Most sites repeat a few placement patterns: a top unit near the header, one or more in-article units, sometimes a sidebar unit on desktop, and occasionally a footer or sticky unit. Each placement has different constraints. Header areas may have more horizontal space but need careful design so they don’t push content too far down. In-article placements must respect reading flow. Sidebars can support taller units but require breakpoints so they don’t collapse on smaller screens.
This is why a “core set” approach works so well. Instead of dozens of sizes, you standardize a small group that covers most templates: a mobile banner (320×50 or 320×100), an in-article rectangle (300×250 or 336×280), a desktop header option (728×90 or responsive), and one sidebar unit (300×600 or 160×600). Once that system is stable, you can test optional expansions like 970×250 for wide desktop headers or additional rectangles in very long guides.
How to Measure Container Width Correctly
Many sizing mistakes happen because people measure the wrong thing. The viewport width is not the same as the content column width. Your site likely has padding, margins, and UI elements that reduce the usable space inside the container. If you measure only the viewport, you might pick a unit that “should” fit but actually overflows once padding is applied.
A reliable workflow is to measure the real content column width at key breakpoints: a small mobile width (for example ~360–400px), a tablet width, and one or two desktop widths. The Fit Checker in this tool is designed for that workflow: you enter your viewport width and your content column width, then see whether a chosen unit fits with zero overflow. If it doesn’t fit, you’ll get safer alternatives.
In-Article Units: Readability First
In-article placements can monetize well because readers actually scroll through content. But they’re also the fastest way to make a page feel “ad-heavy” if spacing is inconsistent. Many publishers start with 300×250 for in-article because it’s compact enough to fit most columns and common enough to attract broad demand. 336×280 can also work on wider columns, but it’s easier to break layouts if your container is narrow.
The best in-article strategy usually includes two rules: don’t place ads too close to major headings, and keep a consistent rhythm between placements. If your content uses lots of short paragraphs or lists, you may need fewer in-article units to preserve flow. If your content is long and sectioned, you can often place units near natural breaks where readers pause.
Header and Footer Units: Visibility vs Disruption
Header units can have excellent viewability, but they come with tradeoffs. A large unit at the top can push content down, which can affect the “first impression” of a page. A compact top unit may preserve the layout but deliver less space for demand. Many sites use a lightweight top option and then rely on in-article placements for the rest. Footer units are often less disruptive and can work well on long reads, but their value depends on how many users reach the end.
If you want a “premium” desktop header option, you must confirm your layout width supports it. The 970-wide formats (970×90, 970×250) require a genuinely wide container and are not safe on most narrow content columns. They can be a great fit for wide layouts, but they should be paired with responsive behavior and breakpoints so mobile never attempts to render them.
Sidebar Units: Stable, Desktop-Oriented Inventory
Sidebars can be a good place for stable fixed sizes because their widths are often predictable on desktop. Classic sidebar formats include 300×600 and 160×600. A tall unit can stay visible longer as a user scrolls—if your layout supports it. The key is to ensure your sidebar collapses cleanly on tablet and mobile, where sidebars often move below content or disappear.
If your site uses a single-column layout on mobile (as most do), treat sidebar units as desktop-only by design. This reduces clutter and avoids layout shifts when the page reflows between breakpoints.
How to Build a “Core Set” for a Whole Site
A core set is a small list of sizes you commit to using everywhere. It helps your templates stay clean and predictable. It also makes your reporting easier, because you can compare performance across pages without dozens of one-off units. For many sites, a good starting core set looks like this:
- Mobile banner: 320×50 (and optionally 320×100)
- In-article rectangle: 300×250 (and optionally 336×280 on wide templates)
- Desktop header: 728×90 (or responsive header unit)
- Sidebar: 300×600 or 160×600 (desktop-only)
What if your site has unusual widths? That’s normal. The right core set is the one that fits your real container widths without hacks. Use the Fit Checker to test your smallest column first. If a unit does not fit that smallest column, it is not “core.” Keep it optional for wider templates only.
Fit Checking: Avoiding Overflow and Layout Shifts
A unit can fail in two ways: it can overflow (too wide) or it can cause layout shift (space not reserved, content jumps when the ad loads). Overflow is easier to catch because you can measure widths. Layout shift often requires template discipline. If you know you’re going to use a fixed unit, reserve the space. If you use responsive behavior, ensure your containers are stable and your page doesn’t reflow unpredictably.
The Fit Checker is intentionally simple: it answers the first question you must solve—does the unit fit your container? After that, you can refine with spacing, performance testing, and design polish.
Testing Strategy: What to Change First
If you want to improve performance, start by improving fit and viewability, not by adding more sizes. A cleaner layout can increase time on page and scroll depth, which can improve viewability. Once your core set is stable, test one change at a time: swap one in-article unit size, adjust header behavior, or try responsive in a single template. Track results using engagement signals (bounce rate, time on page, scroll depth) and ad metrics (viewability, fill, RPM) together.
The biggest wins often come from “boring” improvements: fewer layout bugs, fewer overflows, and more consistent templates. Users notice when pages feel clean. Ads can still monetize well when they feel like part of a well-designed page.
FAQ
Ad Unit Size Guide – Frequently Asked Questions
Quick answers about common ad sizes, mobile vs desktop choices, responsive units, and how to avoid overflow.
Common display sizes include 300×250 (medium rectangle), 336×280 (large rectangle), 728×90 (leaderboard), 320×50 (mobile banner), 300×600 (half page), and 160×600 (wide skyscraper). The best choice depends on your layout and device mix.
Mobile-friendly sizes typically include 320×50 and 320×100. Many sites also use responsive units that adapt to available width, which helps avoid overflow on smaller screens.
A responsive ad unit adjusts its width (and sometimes height) to fit the container. It helps prevent layout breakage across devices and can improve user experience when your content column changes with screen size.
Measure your content column width (in pixels) at common breakpoints and compare it to the unit width. This tool includes a fit checker that flags overflow and suggests alternative sizes that fit.
Many publishers use 300×250 or 336×280 in-article because they fit most content widths on desktop and can be placed between paragraphs. On narrow layouts, responsive units or 300×250 are usually safer.
On desktop, 728×90 and 970×90/970×250 are common header choices when the layout supports it. On mobile, 320×50 or 320×100 are common. Always prioritize readability and avoid pushing content too far down.
Not always. Larger units can increase viewability and demand, but performance depends on placement quality, layout, audience, and page speed. A smaller unit in a high-viewability spot can outperform a large unit placed poorly.
IAB sizes are common standards used across many ad platforms. Some networks and formats (like responsive or native) can support additional behaviors beyond fixed sizes. It’s best to design around widely supported standards.
Using a smaller set of consistent sizes often makes layouts cleaner and easier to manage. Many sites standardize 3–6 core sizes across templates, then expand only when testing shows a clear benefit.
Yes. You can export filtered sizes to CSV and reuse them as a reference for templates, breakpoints, and documentation.