Book cover requirements that break KDP uploads

Amazon's eBook cover criteria page says your cover image must be less than 50MB. Amazon's Cover Image Guidelines page says 5MB or fewer. Both were live on July 30, 2026, both describe the same JPEG, and they are ten times apart. That is how two authors can each follow "the KDP book cover requirements" and end up building to different documents. There is no single spec sheet. There is a help center full of pages written at different times and never reconciled, and the requirements that bounce an upload are usually not the ones the spec posts copy off each other. Every item below carries the failure it causes and the way to catch it before Amazon does.

What Amazon actually checks when you press upload

Two separate pipelines look at your cover files, and neither one is the help page you read beforehand. An ebook cover goes up as an image and is validated as an image. A print cover goes up as a PDF, gets converted, and then comes back at you in Print Previewer, which is a second gate with its own veto.

That veto is written down. KDP's page on fixing paperback and hardcover formatting issues says that if the file is sized at dimensions other than those expected, Print Previewer will note the discrepancy and prevent approval. Not warn. Prevent. A print cover built to a trim size you guessed at does not get quietly resized to fit. It stops.

The same page lists a cover file with more than one page as an upload error, and says the front cover, spine, and back cover have to fit on one page. Export a two-page spread out of a layout application without collapsing it and that is your rejection. That page also says there should be no white space around the edges of the cover file or it may fail for bleed. That is the sentence almost nobody reads.

Then there is bulk. Create a Paperback Cover says cover files larger than 650MB won't convert, and recommends 40MB or less.

Checking all four takes two minutes and no software you don't already have. Open the exported PDF and count the pages; the answer is one. Read the document dimensions off the properties panel and compare them against the template you built from, digit by digit. Zoom to 400% and walk the four outer edges looking for anything white that ought to be art. Then glance at the file size in your file browser before you upload it.

The ebook cover spec, and the three places Amazon contradicts it

2,560 pixels tall by 1,600 pixels wide, a height-to-width ratio of at least 1.6:1, RGB, saved as a JPEG. That is the ebook cover size KDP's criteria page calls ideal, with a floor of 1,000 by 625 and a ceiling of 10,000 pixels in either direction, and the Cover Image Guidelines page adds the color instruction outright: use RGB, because Kindle does not support CMYK. Build to those numbers and pixels stop being your problem.

The disagreements start immediately after.

File size first. The eBook cover criteria page says your cover image must be less than 50MB. The Cover Image Guidelines page says 5MB or fewer. I opened both on July 30, 2026 and both were serving. Ten times apart, same image, same company, two tabs you can check for yourself right now. I am not going to tell you which figure the validator enforces, because neither page says so and I have not tested it. The useful part is that the disagreement costs you nothing: export under 5MB and the 50MB number can never be what stops you.

Then the two different floors. The criteria page puts the minimum at 1,000 pixels tall by 625 wide. The guidelines page says covers with less than 500 pixels on the shortest side are not displayed. Two different floors, and the second is about display rather than acceptance, which is the worse failure of the two. A file can be accepted and then not shown.

Format is the easy one. The criteria page accepts TIFF or JPEG. The guidelines page says JPEG is the preferred format. Ship a JPEG and the question evaporates.

Dimensions are only half of what gets a cover bounced anyway. The guidelines page also rules on what is printed on the art: no pricing or temporary promotional offers, no typos, no watermarks, no placeholder or template text. A cover carrying "Your Title Here" in a corner is a perfectly specified file and a rejected one.

Ignore the dpi number on your ebook cover

Ignore it. The dpi tag on a screen-only cover is metadata, not a requirement, and a 2,560 × 1,600 JPEG saved at 72 dpi and the same image saved at 300 dpi are the same picture on a Kindle, pixel for pixel. Resizing files to chase a dpi figure is the single most wasted hour in indie cover prep.

Amazon caused this one. Two of its pages carry three numbers between them:

• The eBook cover criteria page carries a 72 dpi figure and, on the same page, a minimum resolution of 300 PPI.
• The Cover Image Guidelines page states a 300 DPI/PPI minimum.

The strongest argument against me is not a stupid one, so here it is at full strength. A stated minimum is a stated minimum. Complying costs nothing. And the dpi tag is exactly what a layout application reads to compute physical size the moment that file gets placed anywhere physical, so telling people to disregard a published figure in order to save five minutes is careless advice.

I concede the second half of that completely. Any file that will ever be placed at a physical size, a print interior or a paperback wrap or a postcard, should carry a 300 dpi tag, because the tag is the instruction the layout program follows. Where I hold the line is the ebook cover itself. It is displayed on a pixel grid, never at a physical size, so a file that meets the pixel spec and carries a 72 dpi tag looks identical to one that carries 300.

Then do the free thing anyway. Set the tag to 300 in the export dialog. One dropdown, and no pixels change. What you should not do is resample a correctly sized image upward because a dpi calculator handed you a bigger number. Count pixels. Set the tag. Move on.

A print cover is one PDF, and the math isn't optional

A print cover is a single PDF holding the back cover, the spine, and the front cover as one image, with artwork placed at a minimum of 300 DPI. Create a Paperback Cover states both, and both are where the mental model usually breaks, because most people think of the front as the deliverable and the rest as trim.

Bleed comes next. That page asks for 0.125" (3.2 mm) added to the top, bottom, and outside edges. KDP's trim size page states the same requirement from the other direction: objects must extend past where the page will be trimmed by 0.125" (3.2 mm). The second phrasing is the one to remember, because bleed is not margin. It is art you are agreeing to lose.

The size of the whole thing comes out of two equations KDP publishes:

Cover Width = Bleed + Back Cover Width + Spine Width + Front Cover Width + Bleed

Cover Height = Bleed + Trim Height + Bleed

Every term is known except spine width, and I am not going to hand you a multiplier for it. No KDP page I read on July 30, 2026 states a per-page spine formula. They route you to the Print Cover Calculator, which takes your trim size and page count and returns a template. Use it. It constrains trim width to 4 to 8.5 inches, trim height to 6 to 11.69 inches, and page count to 24 to 830, while the trim size page gives that last range as 24 to 828. The two-page gap only matters if your book lands in it, and then the honest move is to let the calculator settle it.

Color flips between the two files. Create a Paperback Cover says images should be in CMYK so the cover looks good in print; Cover Image Guidelines says RGB, and that Kindle does not support CMYK. Both are right, about different files. Paperback Submission Guidelines, where people go looking for submission rules, does not state a color space at all. If that is the page you read, you did not see this.

And flatten everything. Unflattened transparencies can make the file print with missing or distorted content, which is the nastiest failure on this list because it converts cleanly and comes back wrong on paper.

Hardcover keeps the shape and changes the numbers. Same single PDF, same 300 DPI minimum, same 650MB conversion ceiling and 40MB recommendation, plus a 0.51" (15 mm) wrap past the front cover edge and 0.4" (10 mm) between the spine and the safe area for the hinge. That wrap has nothing to do with bleed. It is case-wrapping allowance, and anything you put there goes around the edge of the board where nobody sees it.

The 79-page spine rule has a hole in it

Create a Paperback Cover says KDP only prints spine text on books with more than 79 pages. Fix Paperback and Hardcover Formatting Issues phrases the same cut-off as a book with fewer than 79 pages that can't have text on the spine. Read literally, a 79-page book falls between them. If you are within a few pages of 79, leave the spine plain or add pages. Spine text needs 0.0625" (1.6 mm) of clearance from the spine edges.

Ebook and print, side by side

Read down the column you need, then read across the rows where the two columns disagree, because the disagreements are what kill first uploads. The ebook file and the print file are not versions of each other. They are two different products made from the same artwork, and the row that catches people is color, because RGB and CMYK means you export the artwork twice.

Two rows deserve a second look. Bleed exists only in the print column, and it is artwork you will never see again after trimming. Max file size is the row where Amazon argues with itself twice over, once across the two ebook pages and once between the recommended 40MB and the 650MB conversion ceiling on print. Build to the smaller number in both rows and neither dispute can reach you.

The failures that have nothing to do with pixels

A file can hit every number in that table and still bounce. Most of the submission failures KDP names by name are about what is riding inside the file rather than how large it is, and none of them are visible when you look at the cover on screen.

1. Locked or encrypted files. Paperback Submission Guidelines lists these as a cause of failure. Open the PDF's security properties and confirm nothing is set; an export preset carried over from a client job is the usual culprit.
2. Crop marks, trim marks, bookmarks, comments, invisible objects, annotations, placeholder text, or metadata. All named on the same page. Export without printer marks, then open the file and check the layers and comments panels rather than trusting the dialog you just clicked through.
3. Fonts not embedded in the native program before publishing. Also from Paperback Submission Guidelines, and note the phrasing: embedded in the native program, before the PDF exists, not patched afterward. Check the fonts panel of the exported PDF and look for anything not marked embedded.
4. Type under 7 points. The stated minimum font size is 7 points. Copyright lines, imprint names, and ISBN captions are where this gets violated, because they get set small on purpose.
5. Unflattened transparencies. Create a Paperback Cover warns these can print with missing or distorted content. Flatten before export and inspect the result, not the source document.
6. Content printed on the art. Cover Image Guidelines rules out pricing and temporary promotional offers, typos, watermarks, and placeholder or template text. A stock comp still carrying its watermark is a file that passes every dimension check.

That list is the same pre-flight a print shop used to run by hand, and I ran it by hand for five years before KDP automated the checking. The automation is genuinely better than a tired human at 6pm. What it lost is the explanation of which of the six it was.

What a generated cover clears, and what it can't

What AthenaCover hands back at the end of a run is a finished ebook front cover with the title and author name set as real, legible type, which clears two of the ebook column's requirements that generated art normally fails: RGB output, and letterforms that were actually set rather than approximated inside the picture. The first round is free, so the cost of finding out whether the brief works is an evening.

Check the export yourself before it goes anywhere. Open the file, read the pixel dimensions, compare them to 2,560 × 1,600, and read the file size against the 5MB figure rather than the 50MB one.

Now the part that should stop some of you from buying. It hands you a screen-ratio front cover. That is not a print wrap and it cannot be stretched into one. A wrap is a single PDF carrying the back cover, spine, and front as one image, with 0.125" of actual artwork past the trim on the top, bottom, and outside edges, and KDP's formatting troubleshooting page names white space around the edges of the cover file as a reason a file fails for bleed. Padding a front cover out to wrap dimensions gives you two moves and both are bad: scale the art up until the bleed is covered, which drives your title toward the trim line and can crop it, or pad with flat color and hand Amazon exactly the white margin it told you would fail. If your book is paperback-first or hardcover-first, do not buy an ebook cover expecting to grow it later.

Build from the template, not from the help page

Download the Print Cover Calculator template for your trim size and page count before you draw anything. Drop the art into it. Export one flattened PDF, one page, fonts embedded, no printer marks. Then check the two numbers Amazon disagrees with itself about: get the ebook file under 5MB so the 50MB page cannot matter, and set the dpi tag to 300 without resampling a single pixel, so the dpi argument cannot start. Whichever of those two pages you skipped is the one your rejection notice will turn out to be about.