Unity Ads HTML5 playable specs: the current documented package rules

Unity’s current User Acquisition documentation states a concrete HTML5 playable package for Unity Ads: one inlined, minified index.html, under 5 MB, MRAID 3.0, dual orientation, no blocking close UI, no automatic store redirect, store CTAs via mraid.open, and playable content gated on viewableChange. This is a current-requirement record for producers shipping to Unity Ads User Acquisition. It is not a dated announcement, and it does not cover LevelPlay or ironSource exchange media specs.

What the live docs require

The dedicated Playable asset specifications page (Unity Grow / Unity Ads User Acquisition; accessed 19 September 2026; page shows only relative “Last updated a year ago”) lists the package rules as follows.

Playable creatives must be:

• contained in a single HTML index.html, with no links to other files or folders
• an inlined, minified file
• under 5 MB
• compliant with MRAID 3.0

Outside MRAID, Unity also documents that advertisements must stay in a single HTML file with all assets inlined; Android games must use Android 4.4 or higher; iOS games must use iOS 9.0 or higher; ads must not block the close button or other container UI; ads should support both portrait and landscape; ads should not need network requests (XHR), though analytic calls without personal data may be permitted if they comply with law and platform policy; ads should not automatically redirect to the app store; call-to-actions should open the store with mraid.open; and ads should wait for the MRAID viewableChange event before starting playable content.

A companion Creative specifications page (last updated “2 months ago” on access) restates the same playable package and adds playable end-card notes: a single inline responsive HTML file up to 5 MB, MRAID 3.0, minified, both orientations, respect isViewable, and a store CTA. On several behavioural rules the companion page uses “must” where the dedicated playable page uses “should”. Treat the dedicated playable page as the primary package source and record the stronger companion wording as a second check, not as a separate product line.

Neither page states a calendar announcement date or an enforcement effective date. Do not invent one from the relative “last updated” labels.

Who this affects

The useful operator job is package QA before upload, not reconstructing rules from third-party blog posts. A producer comparing a build should verify file shape (single inlined index.html), byte size against the 5 MB ceiling, MRAID version assumptions, orientation support, close-button clearance, absence of automatic store opens, mraid.open CTAs, and a viewableChange gate before interactive content starts.

This record applies to Unity Ads User Acquisition playables as documented on those pages. It does not establish LevelPlay or ironSource exchange delivery rules, does not prove a specific creative will pass moderation in a given account, and does not measure CPI, completion or store conversion.

Requirement card

Download the current-requirement record. The CSV separates documented facts from editorial recommendations and unknowns.

Evidence boundary

Observation: the two Unity documentation pages above state the package and behavioural rules summarised here. Vendor claim: these are Unity’s stated creative requirements for User Acquisition playables. Editorial inference: teams should keep a build checklist against these fields and re-verify before upload because relative “last updated” labels are not calendar version pins.

Further reading in the existing archive: The playable spec sheet: what to send a network before you build; Playable ad file size budgets by network. Those pages are archive background; this check does not independently re-verify every claim in them.

Research checked 19 September 2026. Local draft; human editorial review and byline assignment pending.