HTML banner requirements

A ZIP, an entry page, a declared size, and everything it needs inside it. The rest of this page is what happens if one of those is missing.

What you upload#

One .zip. Inside it, at least one .html file — that is the only hard requirement, and an archive without one is refused with that message. The upload itself is capped at 512 MB; the limit you will meet first is your own storage, which is counted on the unpacked size and not on the archive, so a small ZIP that expands to a gigabyte is refused after unpacking and nothing is charged against your quota.

Which page starts#

An index.html at the top level of the archive, if there is one. Failing that, the platform looks for any page at the top level, then for an index.html deeper in, then for any page at all — preferring the smallest, which is almost always the entry rather than a component. A wrapper page that only frames another page is followed to the page it frames, which is what an Adobe Animate export looks like.

Note

__MACOSX folders and ._ files are ignored, so a ZIP made on a Mac by right-clicking a folder works as it is. You do not need to strip them.

Declare the size#

Put the authored size in the page, so a screen can enlarge the banner without distorting it. The standard meta tag is read first:

In the head of your entry page

<meta name="ad.size" content="width=1080,height=1920">

Without it, the platform falls back to the dimensions of a <canvas> element or to an Animate export's own declaration. If none of those exists, the banner has no authored size and is stretched to fill whatever zone it plays in — which is how a 300×250 creative ends up spread across a portrait screen.

Everything inside the archive#

No external URLs. A screen keeps playing from its own disk for seven days without a connection, and it can only cache what came in the ZIP — a font, a script or an image fetched from the internet is the part of your banner that is blank in exactly the situation the player exists for. Fonts, libraries and images all travel with the creative, referenced by relative paths.

Creatives run inside a sandbox. Scripts and animation work normally. Three things do not, by design, and a banner that depends on them will look broken only on a screen:

No storage. localStorage and cookies are unavailable and throw when touched. A banner cannot remember anything between plays, and should not try to.
No navigation and no pop-ups. window.open and any attempt to move the player elsewhere are blocked. A screen has no back button and nobody to press it.
No forms. Nothing on a screen is filled in by a passer-by.

How long it plays#

The playlist decides, not the banner. A creative is given the number of seconds set against it in the playlist and is then replaced, wherever its animation happens to be — so a banner should loop, or hold a final frame worth looking at. There is no signal a banner can send to ask for more time.

Before you send it#

Open the entry page from the unpacked folder, offline, with the network switched off. What you see is what a screen sees.
Check the size in the tag matches the size you designed at.
Let it run three times as long as the playlist slot and watch the last frame.
Look for requests going out: browser dev tools, network tab, and nothing to an outside host.

A banner that plays here but not on the screen

Almost always one of two things: it fetches something from the internet, or it relies on storage. Both work on your laptop, and neither works in the sandbox on a screen that may also be offline.