A+ Content Image Sizes: Why You Should Check the Live Upload Prompt

Why there's no single chart to check against

This is worth contrasting directly with the standard gallery precisely because the two systems get treated as if they follow the same kind of rule, and they don't — the gallery's spec is a fixed, universal number regardless of category, while A+ Content's image requirements are per-template by design. Applying gallery habits ("I know the number, I don't need to check") to A+ Content is exactly the gap this page exists to close.

The standard image gallery has one well-defined spec: 500-10,000 pixels, white background, 85% frame fill for the main image. A+ Content doesn't work the same way, structurally — it's a set of different module templates (a full-width banner, a three-image comparison row, a text-and-image split) and each template's image slots are shaped differently to fit that template's specific layout. A pixel dimension that's correct for a full-width banner is wrong for a three-column comparison module, because they're different-shaped containers.

What Amazon does publish

Worth taking this file-size guidance seriously on its own terms, separate from the pixel question — an image well under 2MB that's still needlessly large for its actual pixel dimensions (an uncompressed export, say) can slow the module's load time on the product page, which is a genuine, if smaller, performance cost distinct from anything to do with how sharp the image looks.

Amazon's own A+ Content design guidance states image files should be no larger than 2MB — a file-size rule, not a pixel-dimension one. That's a genuinely useful, universal constraint (keep files compressed and reasonably sized regardless of which module they're going into), but it doesn't answer "how many pixels wide should this specific banner image be," which is the question that actually determines whether an image looks sharp or gets stretched and blurred once placed into a module.

Where the actual dimensions live

This also means the right workflow order is check-then-design, not design-then-check — pulling up the module's live upload prompt before a designer starts building the asset avoids the wasted cycle of building to a remembered or guessed dimension, uploading, seeing it stretch, and rebuilding to the correct size after the fact. The check costs seconds; the rework costs a full design pass.

Each module template inside the A+ Content builder shows its required or recommended image dimensions directly in the upload interface for that specific slot — this is the live prompt referenced in the title, and it's the only consistently reliable source, because it reflects whatever that specific template currently expects rather than a static number that could be out of date the moment Amazon adjusts a template. A guide published a year ago listing "the A+ banner image size" as one fixed number is describing a snapshot that may not match the current builder.

A worked example: the cost of skipping this check

This class of mistake is common precisely because it's forgiving in the short term — nothing breaks, nothing errors, the page publishes and looks fine on a quick glance. That forgivingness is what lets it persist across a whole catalogue: there's no failure event that forces someone to go looking for the cause, unlike a suppressed listing or a rejected upload that demands immediate attention.

Run the same scenario across a full seven-module Premium build rather than one banner, and the cost compounds — a single wrong dimension is a minor, easily-missed flaw; the same mistake repeated across several modules because they were all built from one remembered reference dimension produces a page that reads as subtly unpolished throughout, without any single obvious error a reviewer's eye would catch and flag.

A designer builds an A+ full-width banner at 1200×300 pixels based on a dimension they recall from a previous project, uploads it, and the module builder accepts and displays it — but stretched slightly to fill a container it wasn't quite sized for, softening detail and making text (where used) marginally harder to read. Nothing failed loudly; the module published, technically working, just not at its best. Checking the live upload prompt before building the asset, rather than after a stretched result is already live, would have caught the mismatch at the design stage instead of the review stage.

What to do when a module looks slightly off after publishing

It's worth checking this on both desktop and mobile rendering specifically, not just one — a dimension mismatch that's barely noticeable on a large desktop screen can be considerably more visible on a smaller mobile viewport where the same stretch or crop takes up proportionally more of the visible frame, and mobile is where most A+ Content is actually being viewed.

Before assuming a design or content problem, check whether the uploaded image's actual dimensions match what the module's upload prompt currently specifies — a slightly soft or stretched image is a common, purely technical symptom of a dimension mismatch, distinct from a genuine design quality issue. Re-exporting the source image at the prompt's current recommended size, rather than reworking the design itself, is often the entire fix.

Why this is worth building into the process, not just knowing once

The broader lesson generalises to any Amazon spec that lives inside a tool's live interface rather than a static published document — module dimensions here, a category style guide elsewhere, a bullet field's character counter elsewhere still. Building "check the live tool" into a standing process, rather than relying on a remembered number from the last time someone looked, is the pattern that holds up as Amazon adjusts these interfaces over time.

These come from Full Circle, a full-service Amazon management company with $500M+ in managed revenue across 100+ brands. Dr. CRO's A+ image generation checks each module's current live dimensions at build time rather than working from a cached reference, on the reasoning that a spec this easy to check and this easy to silently get slightly wrong deserves a process-level fix rather than relying on someone remembering to look it up every time.