An HTML5 banner is a display ad built as a small web page: HTML for structure, CSS for layout and animation, JavaScript for anything that moves or responds. It replaced Flash as the standard for animated display ads, and it is what ad servers, programmatic exchanges and Google's display network expect when an ad needs to do more than show a still image.
Building one is not hard. Building one that every ad server accepts first time is a matter of knowing the conventions: the sizes, the file weight, the click-through mechanism, and each platform's packaging rules.
Standard HTML5 banner sizes
Most inventory is sold in a handful of IAB standard sizes. Building these first covers the large majority of placements.
- 300x250 — medium rectangle. The most widely available unit, used on desktop and mobile, in content and in apps.
- 320x50 — mobile leaderboard (mobile banner). The thin strip at the top or bottom of mobile pages and apps.
- 728x90 — leaderboard. The wide desktop banner above content.
- 160x600 — wide skyscraper. The tall unit in desktop sidebars.
- 300x600 — half page. A large, high-impact sidebar unit.
- 320x480 — mobile interstitial (portrait full screen on a phone), with 480x320 for landscape.
Ad servers that support responsive or fluid ads will stretch a creative to fit its slot, but most display campaigns still trade in fixed sizes, and a creative built for one size rarely looks right at another without its own layout. Design each size, do not scale one.
File weight
Display ads are judged on how much they ask the page to download. IAB guidance separates an initial load — what loads before the ad is shown — from a subsequent, or polite, load that can follow once the page has finished. Ad servers, exchanges and publishers set their own caps on both, and they vary, so the reliable rule is to read the spec for the placement you are buying rather than relying on a single number.
Whatever the cap, the techniques for staying under it are the same:
- Compress images properly: export at the exact pixel size needed (twice that for high-density screens only where it matters), use WebP or optimised JPEG and PNG, and avoid full-frame photographs where a flat colour would do.
- Prefer CSS animation to animated GIF frames or video. A transform on one image costs almost nothing; twenty frames of the same image cost twenty times.
- Use system fonts or a small subset of a web font containing only the characters you need.
- Avoid heavy animation libraries for simple motion. A full library can outweigh the rest of the banner.
- Count everything in the ZIP, including files you no longer reference.
clickTag: how a banner knows where to go
A banner does not hard-code its landing page. The ad server passes the destination in at serve time, usually as a variable called clickTag, and the creative opens whatever URL that variable holds when clicked. This lets the ad server track the click and lets the trafficker change the destination without rebuilding the ad.
- Declare the variable in the HTML head, in the form your ad server documents — typically a global variable named clickTag holding a placeholder URL.
- Make the whole banner, or the button area, clickable, and on click open window.clickTag in a new window.
- Do not add your own URL, tracking parameters or redirects in the code; the ad server supplies them.
- Check the spelling and capitalisation your platform requires. Some servers expect clickTag, others clickTAG, and multiple exits use numbered variables.
In-app is different
Inside mobile apps, interactive creatives run through MRAID rather than clickTag: the ad calls the container's own open function instead of opening a window. If a banner will run in apps as well as on the web, it usually needs a separate build. MRAID vs VAST and VPAID explains where each standard applies.
Animation rules
Most publishers and ad platforms limit how long a banner may animate, how many times it may loop, and how fast it may flash; Google Ads, for example, limits animation length and loops, and many publishers follow IAB guidance for shorter limits still. Design the animation to land on a strong final frame — logo, message and call to action — because that is what most viewers will see. Avoid rapid flashing, both because platforms reject it and because it can cause harm to people with photosensitive conditions. Sound should never autoplay; where it is allowed at all, it should start only on a tap.
Uploading HTML5 ads to Google Ads
Google Ads accepts HTML5 display ads as a ZIP file, subject to account eligibility and a published size limit. The essentials:
- One HTML file at the root of the ZIP, with every image, script and stylesheet included and referenced by relative path.
- An ad.size meta tag in the head declaring the width and height, for example width=300,height=250.
- The click handled through Google's exit mechanism or the clickTag convention it documents, rather than a hard-coded link.
- No external resources beyond those Google allows, and file types limited to the ones Google lists.
- The animation, loop and file-size limits on Google's current HTML5 help page, which is the source to check before every campaign, since the rules change.
Google's own validator flags most problems on upload. App campaigns are a separate case: they accept HTML5 playable assets with their own requirements, covered in the Google App campaigns playable guide.
Tools for making HTML5 banners
Google Web Designer
Google's free desktop tool for HTML5 ads. It has a timeline, components and export presets for Google Ads, Display and Video 360 and other environments, and it handles the clickTag and exit wiring for its targets. It is the default choice for teams buying mostly through Google.
Design-led banner tools
Several web-based tools let designers animate banners from a layout and resize a master design into every IAB size at once. They are the fastest route when the job is many sizes of the same message.
Hand-coded
A developer with plain HTML, CSS and a small amount of JavaScript can build the lightest banners possible and has full control over every byte. The cost is time per size and per variant.
A quick checklist before trafficking
- Every size built with its own layout and tested at actual pixel size.
- Total weight inside the strictest cap you are buying against.
- clickTag or the platform's exit method wired, with no hard-coded destination.
- Animation length and loops within the limits; a clear final frame.
- A backup static image supplied for environments that cannot run HTML5.
- Tested in more than one browser and on a real phone for mobile sizes.
When a banner should be more than a banner
A banner is built to be glanced at. For an app or game, the stronger formats in mobile inventory are full-screen and interactive: interstitials, rewarded placements and playables, where the viewer can try the product instead of reading about it. The rich media versus playable ads guide covers where display creative ends and in-app interactive creative begins.
Playable Ads Maker focuses on that second category. It builds playable ads and interactive end cards without code and exports each one packaged for the in-app network you pick, with the store exit already wired — the in-app counterpart of what Google Web Designer does for display. Many teams run both: HTML5 banners on the web for reach, and a playable built from the same art in apps for installs. The size limit tool shows what each in-app network accepts.
Create playable end cards in minutes—no code required.
Open Playable Ads Maker