A+ Content Size: The Limits Beyond Just Image Pixel Dimensions

The four separate things "size" can mean here

Image pixel dimensions — width and height, and whether an image meets the live upload prompt's current requirement — is the one most commonly discussed. But module count is a separate constraint: how many of the available module slots (five for Basic, up to seven for Premium) a build actually uses. Character limits per text field within a module are a third, generally unpublished as one fixed universal number and better checked live in the editor for the specific field being filled. File size in megabytes for an uploaded image, separate from its pixel dimensions, is a fourth — a technically correctly-sized image in pixels can still fail to upload if the file itself is too large.

Conflating these four into one general sense of "size" is how a build runs into an unexpected limit — hitting a character cap while still well under the pixel dimension guidance, for instance, which reads as confusing if you were only checking the pixel number.

Knowing which of the four is actually the constraint in play also determines the right fix — a module-count problem needs content prioritisation, a character-limit problem needs tighter writing, and a file-size problem needs image compression. Applying the wrong fix to the wrong constraint (trimming text when the actual issue is an oversized image file, for instance) wastes effort without resolving anything.

Module count as a size constraint

Basic A+ Content supports up to five modules per ASIN; Premium supports up to seven. This is a size limit in the sense that matters most for planning a build — it caps how much distinct content a page can hold regardless of how much a brand might want to include, which is why the earlier decision about whether genuinely enough real content exists to fill the available slots matters more than any pixel-level detail.

A build that runs out of module slots before it's covered everything worth saying is hitting this constraint specifically, not an image size one — the fix there is prioritising which content earns a module, not compressing images further.

Character limits per module, checked live

Each text field within a module carries its own character allowance, and — similar to the pattern with backend search terms and bullet points — there's no single, universally cited figure that reliably applies across every module type and account. The live character counter inside A+ Content Manager, checked at the time of writing for the specific field being filled, is the reliable source, rather than a number remembered from a different module or a different account's build.

Writing concisely toward a clear point, rather than toward whatever maximum a field allows, tends to produce stronger copy regardless of the exact limit — a pattern that holds across most of these Amazon field-length questions.

File size versus pixel dimensions, and why both matter separately

An image can meet the pixel dimension guidance published for A+ Content and still fail to upload if the file itself, in megabytes, exceeds the platform's current file size ceiling — a high-resolution image saved without compression can be technically correct in pixels and still too large as a file. Compressing the image while preserving its pixel dimensions, using standard image-editing tools, generally resolves this without needing to shrink the actual dimensions.

Checking the current file size guidance published in the live upload prompt, alongside the pixel dimension requirement, before a batch upload avoids discovering this mismatch partway through a build.

Batch-preparing images for an entire A+ build before starting the upload — compressing and renaming the full set at once, rather than one at a time as each is encountered — is a genuinely faster workflow once a build involves more than a couple of modules, and it surfaces file-size problems across the whole set before any of them are attempted rather than one at a time mid-build.

A worked example combining all four constraints

A brand planning a seven-module Premium build for a hero product first checks eligibility (module count constraint: confirmed Premium-eligible), then drafts content for all seven modules and finds only five genuinely earn their place (module count decision, independent of eligibility), then writes each module's text against the live character counter per field (character limit constraint), and finally prepares images at the published pixel dimensions, compressing any file exceeding the size ceiling before upload (file size constraint).

Working through all four in this order — eligibility, content, text, then images — avoids the common failure of producing content or images first and discovering a constraint only once the build is nearly finished.

Why understanding all four constraints together helps

72.4% of sessions across managed brands arrive from the Amazon mobile app, where A+ Content that's well within every size constraint still needs to render cleanly on a small screen — a build technically compliant on all four dimensions can still read poorly on mobile if it wasn't previewed there. Dr. CRO checks module count, character limits, pixel dimensions and file size as four separate items in every A+ build, from Full Circle, a full-service Amazon management company with $500M+ in managed revenue across 100+ brands.

Treating each of the four as its own checklist item, rather than one vague sense of "getting the sizing right," also makes it easier to hand off parts of a build to different people — a designer can own pixel dimensions and file size while a copywriter owns character limits, each working against a clear, specific constraint rather than a shared, fuzzy one.