Amazon DSP Creative Specs, Explained

Display: the sizes and file-size caps that actually matter

Amazon's own eCommerce display creative (REC) documentation supports both a responsive option — a single asset that Amazon automatically resizes to fit whatever breakpoints a placement needs — and a fixed set of specific IAB sizes for advertisers who want direct control: 300x250, 336x280, 728x90, 160x600, 300x600, 320x50, 300x50, 414x125, 970x250, and 980x55.

File-size limits are set per size, not applied as one blanket number, and this is the part most creative teams get wrong on the first upload: standard sizes cap at 100 KB, the 728x90 leaderboard caps lower at 60 KB, mobile sizes (300x50, 320x50, 414x125) also cap at 60 KB, and the large formats (970x250, 980x55) get more room at 150 KB. Accepted formats are JPEG, PNG, GIF and HTML — Amazon's spec table lists HTML alongside the static formats under the same per-size weight caps. An HTML unit keeps loading assets after the ad first renders, so its initial-load weight and its total weight are not the same number; Amazon does not publish a separate initial-load ceiling on that page, so check what the console accepts on upload rather than budgeting against a figure from a spec blog.

The responsive option is worth defaulting to for most brands, specifically because it removes the size-by-size guesswork this section describes. A single well-built asset, submitted once, gets automatically resized and re-compressed to fit whatever breakpoint a given placement calls for — trading some pixel-level control for a large reduction in the number of individual files a creative team has to build, test, and re-upload every time a new size gets added to a campaign.

A worked example: sizing a creative for the leaderboard slot

Say a designer builds a 728x90 leaderboard at 1x resolution, exports it as a PNG, and it comes out at 84 KB. That file will be rejected on upload — it's under the 100 KB standard cap but over the 60 KB cap that applies specifically to that size. The fix is almost never "compress harder" as a first move; it's checking which size-specific cap actually applies before building the asset, because a JPEG re-export at 60% quality to hit 60 KB on a leaderboard will visibly degrade the creative, while the same 60 KB budget is comfortable for a smaller mobile unit with less surface area to render.

The practical order to work in: confirm the exact pixel dimensions and which file-size tier they fall under first, design and export against that number second, and only reach for aggressive compression as a last resort — most rejected uploads in practice are sized correctly but built against the wrong cap for that dimension.

Video and streaming TV: two specs, not one

Amazon DSP video runs as MP4, 16:9 aspect ratio, up to 500 MB, and — per Amazon's own documentation — is currently available in the U.S. only on third-party publisher sites for the standard online-video placement. That's a materially different, stricter product from streaming TV inventory, which runs on connected-TV and OTT surfaces and layers its own requirements on top: audio levels have to meet broadcast loudness standards, not just "loud enough," and duration has to land on one of the lengths the supply source actually accepts rather than anywhere near it. Amazon's own streaming TV spec table publishes those lengths per supply source — in the US, 15, 30, 45 and 60 seconds on Prime Video; 15 and 30 on Twitch; 15, 30, 45, 60 and 90 on Fire TV Channels; and any duration at the publisher's discretion on third-party exchange inventory. The lists differ by locale, so read the row for the market you are buying. A :31 cut that would pass on an online-video placement gets rejected outright on streaming TV.

This split matters because it's the same mistake as confusing display formats: a video asset built for a phone screen inside an app, with fast cuts and on-screen captions because sound is often off, is not automatically fit for a connected-TV living-room screen, where sound is almost always on and the viewer isn't holding the device. Building one video and dropping it into both placement types without adjusting for the viewing context is the single most common creative mistake we see cross the desk, on our own accounts included.

When a creative gets rejected: what to check, in order

A rejected creative is not a mystery if you work through it in the right order. Check the file size against the size-specific cap first, not the general 100 KB standard — this catches most rejections on the first pass. Check the exact pixel dimensions second; a creative built at 729x91 instead of 728x90 fails even if every other spec is correct. For HTML, check the initial-load weight separately from total weight third, because a unit that looks fine as a total download can still render too heavy on first paint. For video, check duration to the frame and audio loudness fourth, especially on anything headed to streaming TV, where both are enforced more strictly than on standard online video.

Where Dr. DSP fits

Dr. DSP is Amazon DSP run as a managed product by Full Circle, which has managed more than $500M in revenue across 100+ brands. In a 31-day pull across 27 advertisers in our own book, mobile-app display units returned 6.29x against 1.46x for video units running in the exact same apps, on the exact same devices, to the exact same audiences — the difference wasn't the targeting, it was the format and the spec discipline behind it. A reader who never buys anything from us should still leave this page knowing that a creative built for one placement's spec sheet rarely performs when reused on another without adjustment.