Digitaland Advertising Blog

This checklist is for agency project managers, producers and ad ops teams who sign off banner files before they go to a trafficker or publisher. It follows the order we use in production, and each line points to the official spec page it comes from. Every platform rule below was checked against those pages in November 2026.

How to run the checklist

Run it twice. Once when the master build is approved, and again on the final ZIPs, after resizes and copy changes. Errors often slip in during the last round of edits.

Work through six stages in order:

1. Build: the HTML document and the size tag.
2. Clicks: the clickTag and exit URLs.
3. Weight: initial load, file count and ZIP size.
4. Fallbacks: backup images and static versions.
5. Packaging: what goes in the ZIP, and what stays out.
6. Handoff: what the trafficker receives with the files.

Before you start, know every destination on the media plan. The same creative often runs on two or three platforms, and each one wants a slightly different package. Our banner ad specs cheat sheet lists sizes and weights by platform.

Need backups for every size? Drop the ZIP. Get the finished frame. JPG, GIF and MP4 in minutes. Free. JPGGIFMP4 Try it free

Where ad platform specs disagree

Most HTML5 specs agree on the basics. The differences sit in a handful of details, and those details cause most failed uploads. This table compares the official pages we opened for this guide.

Sources: Google Ads, CM360, DV360, Ad Manager, The Trade Desk (PDF, March 2025), Amazon Ads and Yahoo.

Stage 1: Build checks for the HTML file

The HTML file is the entry point of the ad. If it’s malformed, nothing else on this list matters. Check these lines on every size:

• The file starts with <!DOCTYPE html> and has html, head and body tags. Google Ads and Yahoo both ask for this.
• The head holds a size tag, such as <meta name="ad.size" content="width=300,height=250">, that matches the slot exactly.
• Sizes are fixed. Ad Manager doesn’t support dynamic sizes such as Fluid in HTML5 bundles.
• Every asset path is relative to the ZIP. Google Ads allows only a short list of outside references: Google Fonts and Google-hosted CreateJS, Greensock and jQuery.
• Every network request uses HTTPS.
• No cookies, local storage or session storage. CM360, DV360 and Amazon reject storage, and Yahoo bans cookies.
• Inline SVG tags have explicit end tags. Google Ads rejects self-closing ones like <path />.
• No leftover console statements. Amazon requires them removed.
• If the ad was built in Google Web Designer, the right environment was selected: Google Ads for Google Ads, Display & Video 360 for Ad Manager.

For the standard slot sizes behind those size tags, see our IAB standard banner sizes guide.

Stage 2: Click-through checks

The clickTag lets the ad server set the landing page and count clicks. CM360 expects the HTML file to include at least one click tag. The variable name is where platforms differ:

• CM360, Ad Manager and DV360 use clickTag in their examples.
• The Trade Desk defaults to clickTAG, and names are case-sensitive. Its spec says clickTag and clickTAG are not interchangeable.
• Amazon Ads wants clickTag, then clickTag1, clickTag2 and so on for multiple exits.
• Yahoo asks that the clickTag definition and click calls stay readable, even when the rest of the code is minified.

Click every exit on every size. Confirm each one opens in a new window, as The Trade Desk requires.

Your HTML5 campaign ZIP goes in. Backup images, GIFs and MP4s come out. Every size. Every platform. Free. JPGGIFMP4 Try it free

Stage 3: Weight, file count and load checks

“Under the limit” means different things on different platforms. Some cap the ZIP. Others cap what loads before the page finishes, or before the user interacts. Measure each one separately.

The IAB New Ad Portfolio also caps the initial load at ten file requests. Use sprites or inline SVG to stay under it.

Heavy ads can also be stopped in the browser. Chrome treats an ad as heavy when it uses more than 4 MB of network data or more than 60 seconds of main-thread CPU in total. If a size is over, our tips to reduce HTML5 banner size are the place to start.

Stage 4: Backups and static versions

Check that every size has a static backup at the exact same pixel size, and that it shows the finished frame. Then check where it goes. CM360 and DV360 want it uploaded separately, Yahoo wants it inside the ZIP, and Amazon wants the fallback built into the ad code. Our guide to HTML5 backup image requirements covers each platform’s rules and weight limits.

Some placements can’t take HTML5 at all, so the static file becomes the ad:

• Email. LiveIntent accepts only PNG, JPG or GIF, because email doesn’t run JavaScript.
• Newer Google Ads accounts. HTML5 needs an account open more than 90 days with more than $9,000 lifetime spend. Others run image or GIF ads, capped at 150 KB and stopping by 30 seconds.

Making these by hand for every size takes time. Our free tool turns an HTML5 banner ZIP into backup images, GIFs and MP4s in one pass. For the GIF itself, see how to convert an HTML5 banner to GIF.

Stage 5: Packaging the ZIP

Packaging is where a correct banner most often fails upload. The rules are simple, but they differ just enough to catch a team sending one ZIP everywhere.

• One HTML entry file per creative, at the root of the ZIP. The Trade Desk and Ad Manager both say not to bury it in subfolders.
• Zip the files, not the folder that holds them.
• Only files the HTML actually uses. CM360 says to include only referenced files, and DV360 says to leave out source and authoring files.
• Allowed file types only. CM360 accepts font files (EOT, OTF, TTF, WOFF, WOFF2). The Trade Desk’s list doesn’t include fonts, but does include MP4.
• No % in any filename (CM360). DV360 caps filenames at 200 single-byte characters, and video or audio filenames at 50.
• No ZIP inside a ZIP. CM360 accepts a ZIP of separate creative ZIPs only for batch upload.
• The backup is beside or inside the ZIP, as Stage 4 requires for that destination.
• For Amazon, the deliverable is a JavaScript or iframe tag from an approved ad server, sent in a .txt or .xls file, not a ZIP.

Name every file so a trafficker can match it to the placement sheet without opening it. If source files are part of the deal, send them in a separate folder. Yahoo, for example, asks for an “original” folder kept apart from the “publish” build.

Stage 6: The handoff package

A trafficker should be able to load the campaign without writing back to ask a question. That depends on what travels with the files.

Our delivery folders include:

1. One ZIP per size, packaged for each destination platform.
2. One backup per size, placed as that platform requires.
3. Static and GIF versions for any email or image-only placements on the plan.
4. A click-through URL for every exit, with the variable name used in the code.
5. Preview links for final client sign-off. Our free banner compare tool plays every size side by side.
6. A short manifest: size, platform, ZIP weight, file count and backup weight for each file.

The manifest is what an ad ops team checks against the spec, so keep it next to the files. For how the files get built before this point, see the PSD to HTML5 banner production process. If running this checklist across hundreds of sizes is more than your team can take on, an HTML5 banner production studio can hand you files that already pass it.

Frequently asked questions

Sources

• Google Ads: Uploaded display ads specifications
• Google CM360: How to prepare HTML5 display assets
• Google DV360: HTML5 creatives
• Google Ad Manager: HTML5 guidelines
• The Trade Desk Creative Specifications (PDF, March 2025)
• Amazon Ads technical guidelines
• Yahoo HTML5 guidelines
• IAB Tech Lab: New Standard Ad Unit Portfolio (PDF)
• Chrome for Developers: Heavy ad interventions
• LiveIntent ad specs