KDP Says Your Cover Is Low Resolution — Even Though It's Already 300 DPI

You checked the DPI. It says 300. You checked it again. Still 300. And yet KDP's cover checker throws a low-resolution warning anyway, sometimes with a vague message about the image not meeting print quality standards. This is one of the most confusing rejection messages in the entire KDP upload flow, because the number everyone is told to check — 300 DPI — is sitting right there in the file metadata looking perfectly fine.

The problem is that DPI, as a metadata tag, is almost meaningless on its own. KDP doesn't actually read that tag to decide whether your cover is high resolution. It calculates whether your file's actual pixel dimensions are large enough to produce 300 real dots per inch at the exact physical size your cover needs to print — full wrap width and height, including spine and bleed. If those two numbers disagree, you get the warning, and the DPI label in your file's properties panel is irrelevant to the outcome.

DPI Metadata vs. Actual Pixel Density

Every image file carries a resolution tag, but that tag is just a hint to software about how to display or print the file — it is not a measurement of image quality. Two files can both say "300 DPI" and have wildly different actual print resolutions:

• File A: 3878 × 2775 pixels, tagged 300 DPI. At a physical print size of 12.9256″ × 9.25″, this is genuinely 300 real DPI.
• File B: 1939 × 1388 pixels, tagged 300 DPI. At that same 12.9256″ × 9.25″ print size, this file is only 150 real DPI — the metadata tag was set manually or preserved from a different export without the pixel count ever changing.

KDP's checker does the math on File B and sees roughly half the pixels it needs. It doesn't care what the tag says. This is the single most common reason writers get a low-resolution rejection on a file they're certain is "300 DPI."

Culprit #1: Your Pixel Dimensions Don't Match Your Trim + Spine + Bleed

The physical size of your cover isn't just your trim size. It's the full wrap: back cover width + spine width + front cover width, plus 0.125″ bleed on each outer edge, plus 0.125″ bleed top and bottom. Spine width itself depends on page count, paper type, and ink type — which means the required pixel dimensions are unique to your exact book, not a generic "6×9 cover" size.

Here's how that plays out for a 6″ × 9″ paperback in black-and-white on white paper, at 300 DPI, as page count changes:

Notice that a 100-page difference in your manuscript shifts the required width by roughly 70–80 pixels. If you designed your cover template for a 250-page draft and your final manuscript came in at 320 pages, your spine got wider — and your existing file, even if it was correctly sized for the old page count, is now too narrow for the new one. KDP will flag it as low resolution because, relative to the new physical dimensions, it genuinely is under 300 DPI.

This is the exact calculation you should run before re-exporting anything. Enter your trim size, page count, paper type, and ink type into the KDP cover calculator and it will return your precise full-wrap dimensions in inches and the exact pixel dimensions required at 300 DPI. Compare that number directly against your file's actual pixel dimensions — not its DPI tag — using your image editor's canvas size or image size dialog (not the print resolution field).

Culprit #2: The File Was Scaled Up After Export

This is the sneakier version, and it's the one that fools people who did the math correctly the first time. Here's the sequence:

1. You (or a designer) build the cover at the correct pixel dimensions for an early draft's page count — say, 3743 × 2775 px for a 100-page book.
2. The manuscript grows to 300 pages. The spine needs to widen, so the full cover needs to be 3878 px wide instead of 3743 px.
3. Instead of rebuilding the canvas at the new size and re-placing full-resolution source images, someone stretches the existing flattened file — via canvas resize, "image size" with resampling enabled, or a drag-handle scale in a page layout tool — to hit the new target dimensions.

The resulting file now has the correct pixel count. It will pass a naive dimension check. But the extra 135 pixels of width were invented by interpolation, not captured from real source detail. The image data underneath is still only as sharp as the original 3743 px version, stretched. Depending on how KDP's automated checker evaluates image quality (it does more than just count pixels — it also looks for signs of upsampling artifacts and unusually soft detail at the pixel level), this can still trigger a low-resolution or image-quality warning, even though the file technically hits the pixel target.

Culprit #3: Silent Downsampling on Export (Canva and Photoshop)

Design tools frequently downsample images during export in ways that are easy to miss:

Canva

• Canva's free-tier PDF export sometimes caps output resolution regardless of your canvas size, especially for very large canvases (full wrap covers for high page counts can exceed 4000 px on one side). Always use "Print" quality PDF export, not "Standard," and verify the exported file's actual pixel dimensions afterward — don't assume the export matched your canvas.
• If you built your design at a smaller canvas size and used Canva's resize feature to scale the canvas up, Canva stretches existing elements rather than re-rendering them at native resolution, reproducing the same interpolation problem described above.

Photoshop

• Image > Image Size with Resample checked will change actual pixel count (and can introduce blur if scaling up). Image > Image Size with Resample unchecked only changes the DPI metadata tag and print dimensions — the pixel count stays identical. Mixing these up is the single most common way a file ends up correctly tagged 300 DPI with the wrong actual pixel count.
• Flattening layers before checking canvas size can obscure the fact that a placed image (like a background photo) was inserted at a lower native resolution than the canvas and then scaled up to fill it. The canvas can be exactly the right pixel size while one visible layer inside it is soft because its source asset was too small.
• Exporting via "Save for Web" instead of "Export As" or "Print" workflows can also silently cap dimensions or apply compression that KDP's checker interprets as quality degradation.

How to Verify True Resolution Before Re-Upload

Don't trust the DPI label. Run this checklist instead:

1. Get your exact required dimensions. Enter your final trim size, final page count, paper type, and ink type into the cover calculator. Note the full wrap width and height in inches and in pixels at 300 DPI.
2. Open the actual export file (the PDF or image you're about to upload, not the working design file) and check its canvas/image pixel dimensions directly — in Photoshop, Image > Image Size with the unit set to Pixels; in Acrobat, Document Properties or a preflight tool.
3. Compare pixel-for-pixel. The exported file's width and height in pixels should meet or exceed the numbers from step 1. If they're lower, the file will fail regardless of the DPI tag.
4. Check for stretch artifacts. Zoom to 100% and 200% on fine detail — text edges, thin linework, small graphics. Soft, blurry, or "waxy" edges at 100% zoom indicate the file was upscaled from a smaller source, even if the pixel count is technically correct.
5. Verify every placed asset, not just the canvas. A correctly sized canvas can still contain one low-resolution photo or logo stretched to fit. Check each embedded image's native resolution before it was placed.
6. Re-export from source, not from the flattened file, whenever spine width or trim size changes. Rebuilding from original layers avoids compounding interpolation.
7. Confirm flattening and embedding. KDP's cover PDF requirements call for all layers flattened and all fonts embedded (see KDP's cover image guidelines, help page G6GTK3T3NUHKLEFX). An unflattened file with live text or vector layers can behave unpredictably in different resolution checks.

Why This Matters More at Higher Page Counts

The wider your spine, the more your full-wrap width diverges from a simple trim-size assumption, and the more likely a page-count change breaks a cover that was correct at an earlier draft. A 24-page chapbook and an 800-page reference book on the same 6″ × 9″ trim need dramatically different canvas widths — and neither has anything to do with the DPI number in your file's metadata. Every time your final page count shifts, treat it as a trigger to re-verify pixel dimensions, not just re-check the DPI tag.

Conclusion

A low-resolution rejection on a file you believe is 300 DPI almost always comes down to one of three things: the pixel dimensions don't match your actual full-wrap size for your final trim, spine, and bleed; the file was upscaled after export and only the metadata was preserved; or an export step in Canva, Photoshop, or another tool silently downsampled something along the way. The DPI tag in your file's properties is not proof of anything — only the actual pixel count, checked against your book's exact physical dimensions, tells you whether the file will pass. Before your next upload, run your specs through the KDP cover calculator to get the precise pixel target for your trim size, page count, paper, and ink combination, then verify your export file's real pixel dimensions against that number directly. That comparison, not the DPI label, is what determines whether KDP accepts your cover.