Paperback Book Cover — front, spine and back, as one wrap PDF

Yes, and you should — for indie publishing, mismatched ebook and print covers make the book read as two products. The front artwork is shared; what a paperback adds is the wrap. Give the builder your front cover, your trim, your final page count and your paper type, and it composes the back cover and spine around it. You need the final page count first, because it is what decides the spine width.

No. The front is placed, not repainted. You choose between cropping it to fill the panel and keeping the whole picture inside it, and the builder tells you exactly what percentage a crop would remove before you commit. The artwork goes into the PDF as its original bytes rather than being re-encoded.

Here is the honest version, because the usual answer is a number about the wrong thing. A PDF has no DPI; what matters is your artwork's pixels divided by the inches they have to cover, which changes with the trim and with how the cover is placed. KDP recommends 300. Both builders compute that figure for your cover at your trim and show it to you before you export — over 300 it says so, under it says so, and it never rounds up. A cover under the recommendation still prints; it prints softer than it looks on screen, and a proof copy is how you decide whether that matters to you.

No — the exported wrap is RGB, and KDP's print guidance recommends CMYK for print images. We would rather state that than imply a conversion we do not perform. The practical risk is colour shift: saturated colours can print noticeably duller than your screen. Order a proof copy and look at it before a launch. If you do run a colour-managed conversion yourself, treat the export as the finished production file it is — a conversion can rasterise the page or change its size, so put the result back through KDP's Print Previewer and confirm the page is still exactly the size your book needs.

Change the number and re-export. Nothing in this product stores a spine width — it is recomputed from page count × paper caliper every time, and the wrap width, the panel positions and the back-cover layout follow it. A late formatting pass that adds twelve pages costs you one re-export. What it does not do is re-flow your artwork: the front cover is the same picture on a slightly different rectangle.

All 16 standard KDP paperback trims for the US store, from 5 × 8 up to A4, including the two square picture-book trims and the landscape one. Page-count limits are a property of the trim AND the paper together, not of the paper alone — 8.5 × 8.5 on cream stops well short of where 6 × 9 on cream does — and the builder checks the real combination rather than the widest one. Covers generated by our AI are offered at a narrower set, because the image model is asked for one shape and a panel of a different shape is a crop.

Page count × paper caliper. White paper is 0.002252 in per page, cream is 0.0025, groundwood is 0.00235, premium colour is 0.002347. A 300-page 6 × 9 on white is 0.6756 in; the same book on cream is 0.75 in. Amazon rounds odd page counts up to the next even number before printing, and so do we. Nothing is rounded after that — the wrap is exported at the full precision the arithmetic gives.

Amazon does not print text on the spine of a book under 80 pages, so the builder stops offering spine text there and says why. Above that threshold there is a second, separate question: whether the spine is wide enough to hold readable type once fold clearance is taken off each side. A 90-page book clears Amazon's rule and still has barely a band. Those are two different refusals and the product keeps them apart — one is Amazon's, one is a typographic judgement of ours, and conflating them would let ours be mistaken for a rule.

The most common mechanical cause is the PDF export interpreting your canvas as US Letter (8.5 × 11) instead of your actual wrap size. The dimensions look right inside the design app and the PDF carries the wrong page size to Amazon. If you are exporting from another tool, set the page size explicitly to the calculator output rather than accepting the app default. If you build the wrap here it cannot arise — the page size IS your trim, page count and paper — and the preflight checker will tell you the measured page size of any existing PDF, next to the size your book actually needs.

They are different reviews. Amazon runs ebook covers through automated checks; paperback and hardcover covers go to a print review that applies tighter rules — text bleeding off the trim, low-contrast typography, decorative borders read as image noise. An ebook-approved cover carries no guarantee for print. That is also the honest limit of what any tool can tell you: we can measure the file, and we cannot see the reviewer.

Yes, and any tool telling you otherwise is describing a review it cannot see. What we can say is what the file contains: one page at the exact size your book needs, artwork reaching every bleed edge, live text inside the safe area, the barcode reserve kept clear, spine text within Amazon’s rules, no font dependency, and the measured print resolution of your artwork. Review also weighs your metadata and your interior, which are not in the cover file at all. Run the export through KDP’s own Print Previewer before you publish.

Not supported here, and worth being precise about why. KDP prints hardcovers as case laminate — your cover art is wrapped around a 2 mm case board and laminated, with no dust jacket involved. The geometry is genuinely different from a paperback: a case wrap adds board wrap on all four edges and a spine hinge of about 0.4 in (10 mm) on each side of the spine that must stay clear of text and barcode, and the spine width is not page count × paper caliper. Modelling it as a thicker paperback would produce a confident, wrong file, so this product declines to compute one. Use Amazon’s own hardcover template for now.