Skip to main content
Display inventory uses three canonical kinds: image, html5, and display_tag. Size, file, interaction, and slot constraints live in params; a size-specific named format ID is not needed.

Static image

Multi-size image

Use sizes[] when one creative contract accepts a closed set of sizes:
Use min/max width and height for a genuinely responsive envelope. Exact-size, multi-size, and responsive modes are mutually exclusive.

HTML5 and third-party tags

html5 describes a buyer-supplied zip bundle that the seller hosts. display_tag describes a third-party-served representation. Keep them separate because validation, hosting, security, and measurement differ. Inline third-party markup is never an html5 bundle. Display tags have three delivery types: The existing tag_url slot remains the backward-compatible default. A seller accepting inline or paired delivery publishes an explicit option with a display_tag slot.

Asset-rendered size

Starting in AdCP 3.3, zip, html, and display_tag assets can describe their own rendered size, independently of a product or format_option_ref. This lets a buyer save a sized HTML5 creative to a library before selecting inventory. Use width and height together for a fixed size. Both are positive integers in logical entry-canvas pixels, independent of embedded image density. For expandable units, these describe the initial canvas; sizes lists alternative entry sizes rather than expanded states. For example, this bundle renders at 300×250:
Use sizes for an asset that can render at any one of several discrete sizes. Each entry contains positive integer width and height, with no additional fields. For example, a third-party tag capable of either size carries:
The same fields apply to inline HTML and every display-tag delivery type, including inline markup and paired redirects. width/height and sizes are mutually exclusive. Omitting all three preserves the existing unsized or responsive asset shape. Responsive min_width/max_width/min_height/max_height bounds remain format-side acceptance constraints. Asset dimensions describe what the creative renders; params describes what a placement accepts. The following checks compare a rendered size with the selected option’s published size constraints. They do not establish full technical acceptance: apply every applicable product, publisher, and placement constraint, including the technical completeness rules. Omitted fields mean no constraint only at a layer that asserts technical_requirements_complete: true; otherwise they remain undeclared. For a multi-size asset, the asset and option need at least one compatible pair. Only compatible pairs may be used when serving that option; matching width from one pair and height from another is invalid. Every listed pair must be renderable by the same supplied representation. The seller must be able to constrain execution to a compatible pair through the representation’s viewport/runtime contract or supported size-macro resolution, such as {AD_WIDTH} and {AD_HEIGHT}. Metadata alone does not make a fixed tag resize. If the seller cannot enforce a compatible rendering, overlap is insufficient and the asset cannot be treated as compatible. When a backup image is required, each eligible serving size also needs a compatible backup. Compare image dimensions in logical rendered pixels, accounting for intrinsic dimensions and pixel_ratio; a 600×500 image at 2× covers 300×250, not 728×90. A repeatable backup slot can provide several images only when the option’s slot declaration permits that array. A single-size backup narrows the sizes at which the main asset can safely serve. For pre-flight previews, select a concrete compatible size through an explicitly narrowed preview manifest or a supported size-macro contract, and check the returned render dimensions. When delivery readback includes a served variant’s resolved manifest, its main asset records the actual rendered width/height rather than leaving a sizes list to be selected again during replay. This describes the served output; it does not mutate the reusable source creative or its revision. Distinct rendered sizes use distinct execution variants under the delivery identity rules. An unsized asset remains schema-valid, but absence of dimensions does not establish a match with a size-constrained option. Additional inspection or validation is needed to establish compatibility. Supplied dimensions are claims about the content and must agree with the actual rendering; they are not proof that the inspected bytes or third-party response satisfy the contract. Size metadata does not replace format_option_ref when multiple options share a format_kind. Product-specific checks apply when the target option is known, whether during sync or assignment; storing a library creative without a target does not assert compatibility with a product. When projecting to size-specific legacy formats, use the main slot asset’s width/height to select a compatible legacy ID. A multi-size asset needs a compatible selected pair and an unambiguous legacy candidate; otherwise the projection cannot choose a size. A creative-level format_parameters object is not part of this contract. The backward-compatible url asset does not gain size fields: to carry size with URL delivery, use a display_tag asset with delivery_type: "tag_url" in an option that declares that asset type.

Inline iframe/JavaScript

Internal Redirect

A two-URL internal redirect is represented portably as paired_redirect; the canonical kind remains display_tag. The asset is atomic so its two URLs cannot be mixed across rows or revisions.
Both fields are required by schema. A half-present pair is invalid. Do not split the pair into independent URL slots. Buyers discover seller acceptance from Product.format_options[]. Creative agents that can build or validate these contracts advertise matching creative.supported_formats[] entries. See Creative representation sets, Canonical formats, Creative manifests, and Universal macros.