--- title: "KDP Says Your Cover Isn't 300 DPI (But It Is) — Why, and the Fix" description: "DPI stored in a file is a label, not resolution. What decides whether a KDP cover prints at 300 DPI is pixel dimensions divided by physical inches — plus the four things that actually cause this rejection." canonical_url: "https://puzzlebindery.com/kdp-cover-not-300-dpi" source: "PuzzleBindery" --- [Home](https://puzzlebindery.com/) › KDP says your cover is not 300 DPI # Your cover is 300 DPI and KDP says it isn’t This is almost always the same misunderstanding, and it is not your fault: the number written in the file and the number that matters are two different things. Once you see the difference, the fix takes a minute. ## What DPI actually is An image file contains a grid of pixels — say 1800 × 2700. Separately, it carries a small piece of metadata saying what physical size those pixels are intended to be printed at. That metadata is the DPI figure your image editor shows you. The two are only loosely connected. You can take the same 1800 × 2700 pixels and label them 72 DPI, 300 DPI or 1200 DPI without altering a single pixel. The file size does not change. The image does not change. Only the label changes. The real resolution is arithmetic: So 1800 pixels across a 6-inch-wide cover is 300 DPI. The same 1800 pixels across a 12-inch-wide wrap is 150 DPI, no matter what the metadata says. ## Why “set it to 300 DPI” does not fix it This is the step that traps people. Your editor offers to change the resolution to 300, so you do, and the file still fails. What that operation does depends on one checkbox, usually called **Resample**: - **Resample off:** the pixel count stays the same and the print size shrinks. Your 1800-pixel image is now labelled 300 DPI and 6 inches wide. Nothing was added — and if you then stretch it back to 12 inches, you are back where you started. - **Resample on:** the software invents new pixels by interpolating between the existing ones. The file gets bigger and the label says 300. But no detail was added, because there was no detail to add. Upscaling produces a larger blurry image, not a sharper one. Neither path creates information that was never captured. The only real fix is to produce the artwork at the right pixel dimensions in the first place. ## The pixel dimensions you need A KDP paperback wrap is a single flat image containing back cover, spine and front cover, with bleed all the way round. Its physical size is: - **Width** = (trim width × 2) + spine width + (bleed × 2) - **Height** = trim height + (bleed × 2) Bleed is 0.125″ on each edge. Spine width is your page count multiplied by the paper’s thickness per page. Multiply the resulting inches by 300 and you have the pixel dimensions the file must actually be. Our [spine width calculator](https://puzzlebindery.com/cover-calculator.html) does this and prints the exact pixel figures, then hands you a blank template already at those dimensions with trim, bleed, the spine fold, the safe area and the 2″ × 1.2″ barcode zone marked. It is free and needs no account. ## Four things that cause this specific failure ### 1\. The artwork was made at screen size Anything designed for a screen starts at screen resolution. A 1200-pixel-wide design looks perfect on a monitor and is nowhere near enough for a 12-inch wrap. There is no recovery except redrawing at print size. ### 2\. The template was the wrong size to begin with If the spine width was estimated rather than calculated, the whole canvas is the wrong width — so even correct-looking artwork lands at the wrong effective DPI once it is scaled to fit. This is the most common version among people who built the cover before finishing the interior. ### 3\. A low-resolution element inside a high-resolution file The canvas can be 3600 pixels wide and still contain a logo or photograph that was dropped in at 400 pixels and stretched. The file passes a naive DPI check and still prints soft in exactly one place. Check each placed element at 100% zoom. ### 4\. It was exported through something that resampled it Some export paths downsample images to save file size, and some PDF presets do it by default. If your source is correct but the export is not, look for a “downsample images” or “compress” option in the export settings and turn it off. ## How to check before uploading 1. Open the cover file and read its **pixel dimensions** — not its DPI label. 2. Work out the wrap’s physical width and height in inches from the formula above. 3. Divide. If pixel width ÷ inches is at least 300, you are fine regardless of what the metadata says. 4. Zoom to 100% and look at the smallest text and any placed image. If step 3 fails, no export setting will save it. The artwork has to be produced larger. ## The related trap Worth knowing while you are here, because the two failures often arrive together: the spine width depends on your page count, so a cover that was the correct size last week is the wrong size after you add pages. Rebuild the cover whenever the interior changes, or use something that derives the spine from the live page count instead of a number you typed once. That is what our cover designer does — the wrap dimensions and the spine follow the book, so the pixel dimensions are correct by construction and cannot drift. ## Related - [Spine width calculator](https://puzzlebindery.com/cover-calculator.html) — exact inches and pixels, plus a 300 DPI blank template. - [Fixing a gutter rejection](https://puzzlebindery.com/kdp-insufficient-gutter) — the interior-side version of the same class of problem. - [Cover Creator or upload your own?](https://puzzlebindery.com/kdp-cover-creator-alternative) - [KDP specs cheat sheet](https://puzzlebindery.com/kdp-specs.html) **More:** [Spine calculator](https://puzzlebindery.com/cover-calculator.html) · [Cover Creator or upload your own](https://puzzlebindery.com/kdp-cover-creator-alternative) · [Fix a gutter rejection](https://puzzlebindery.com/kdp-insufficient-gutter) · [KDP specs](https://puzzlebindery.com/kdp-specs.html) · [Open the Studio](https://puzzlebindery.com/app.html)