I publish books from HTML — and the KDP print rules that rejected me twice

Book interiors are laid out in InDesign, by people who know what a gutter is. I don't own InDesign and I didn't know what a gutter was. What I do own is a text editor and a headless browser, and it turns out a printed page is a box of a fixed physical size with typography in it — which is CSS with a different unit system.

So the pipeline behind the books I publish is: write the content as structured text, lay it out in HTML and CSS, render to PDF with a headless Chrome, and upload that PDF to Amazon KDP. It works. It also got rejected twice before it worked, both times for the same misunderstanding, and that misunderstanding is the most useful thing in this post.

Why HTML for print at all

Three reasons, and only the third one is about money.

First, content and layout stay separate. A hundred-entry book is a hundred records; the layout is one stylesheet. Change your mind about the running head on page 40 and you've changed it on all hundred pages, correctly, in one edit. That's a database problem wearing a typography costume, and the tools I already had are good at database problems.

Second, the build is reproducible. A design file's output depends on the state of the application when a human clicked Export. A script's output depends on the script. When a book needs a fix eight months later, I re-run a command instead of reconstructing a mood.

Third, the cost is zero, which matters when you're testing whether a category sells before you've earned a dollar in it.

Print design tools are built to make one beautiful thing. A publishing pipeline needs to make the same thing a hundred times without drifting. Those are different jobs, and the second one is a programming job.

The four rules that decide whether Amazon accepts your file

These are the non-negotiables I've internalized, in the order that they actually bite.

Rule 1: 300 DPI, and "KDP_Ready" in a filename means nothing

Print resolution is 300 DPI. Not 150, not 72, not "it looks fine on my screen." Every image and every rendered page has to hit it, which for interior art means generating your source assets at print size from the start rather than upscaling later — upscaling adds pixels, not detail.

The trap here isn't the rule, it's inherited files. If you buy or download interior assets, many arrive with reassuring names like KDP_Ready or 300dpi_final. That's a filename, not a property. Open the file, check the actual metadata, and look at it at 100%. I've seen "print-ready" packs that were screen-resolution art with an optimistic name, and Amazon checks the file, not the label.

Rule 2: bleed is binary — and this is what rejected me twice

Here is the one that cost me two rejections, and it's worth reading twice because the intuition is wrong.

Bleed is not a spectrum where "close to the edge" is a bit risky. It is two discrete valid states with a rejection zone between them:

Any ink that ends between roughly 0.001" and 0.374" from the trim edge is the failure case. Why: industrial cutting has tolerance. A design that stops 0.2" from the edge gets a visibly uneven white sliver after trimming — sometimes 0.15", sometimes 0.25", never straight. So the printer refuses the file rather than shipping crooked-looking books.

And the measurement that matters is the ink, not the frame. This is exactly how I got it wrong. My image frame filled the page edge to edge, so I marked the page as full bleed — but the visible artwork inside that frame stopped short, with transparent or white space around it. The frame bled; the ink didn't. Amazon measures what prints.

The check is mechanical, so automate it: rasterize each page, find the bounding box of non-white pixels, convert to inches at 300 DPI, and assert that the distance to each edge is either 0 or ≥ 0.375". A page that fails prints a warning with its number. That check now runs on every book before anything is uploaded, and I have not had a bleed rejection since.

Rule 3: the two settings people get wrong on the way in

Two smaller ones that fail late and annoyingly:

• Export as PDF/X (print), not standard PDF. A generic browser-exported PDF can carry RGB color and unembedded fonts. Print wants embedded fonts and print-safe color. Getting this wrong produces either a rejection or — worse — an accepted book that prints with substituted typefaces.
• Mind the page-count floor. Paperback interiors need enough pages for a spine that can hold a printed title; in practice I plan every book at 100+ pages. A 60-page book isn't a smaller version of the same product, it's a different product with different constraints.

Rule 4: the price threshold that quietly halves your income

This one isn't about files at all, and it's the most expensive mistake available to you.

KDP pays two royalty rates, and which one you get is decided by your list price. Above the threshold you earn the high rate; below it you earn the low one — and the low one is roughly half. For the US store the line sits at $9.99. Price your book at $8.99 to look friendly and you don't lose 10% of your income, you lose something close to half of it, on every single copy, forever.

The equivalent thresholds exist per marketplace in local currency, so if you distribute widely you check each one rather than converting from dollars in your head. It takes ten minutes once, at listing time, and it is the highest-paid ten minutes in the entire process.

Everything else in this post decides whether your book gets printed. The pricing threshold decides whether it was worth printing.

What the pipeline actually looks like

Concretely, minus the parts specific to my content:

1. Content as data — entries in a structured file, not paragraphs glued into a layout.
2. One HTML template + one print stylesheet — page size in inches via @page, margins set with the inner (gutter) edge wider than the outer, running heads and page numbers in CSS.
3. Render with headless Chrome to PDF. Watch for one specific trap: at print widths a headless browser can trigger your mobile media queries and silently lay the whole book out in a phone layout. Scope those queries with @media screen so print never sees them.
4. Cover separately — front, spine and back on one canvas, spine width derived from the final page count, built as an image rather than as text-in-HTML.
5. Automated pre-flight — page count, DPI, and the bleed bounding-box check above. Fail loudly before upload.
6. Visual review of a sample — actually look at ten spreads at 100%. Automation catches specification errors; eyes catch a heading that landed alone at the bottom of a page.

The books this produces are ordinary paperbacks: a couple of reflective non-fiction titles in English — My Rizq Was Never Late and Because My Heart Needed Rest — plus activity and coloring titles like Steampunk Wonders and Cozy Garden Sanctuaries, where the interior-generation-in-code argument is at its most obvious. Same pipeline, different content type.

What I'd tell a developer starting today

Don't start by writing the generator. Start by publishing one deliberately small book through the whole path — file, cover, listing, pricing, live page — so you learn where the walls are while the stakes are nothing. Then automate the part that hurt.

The reason is that the hard parts are not the parts a programmer expects. The layout code is an afternoon. The rules that reject you are undocumented in your head until you hit them, and the decision that determines your income is a number in a pricing form nobody thinks of as engineering. Write the code second.

Sources

• Amazon KDP print specifications — trim sizes, bleed dimensions, file format and page-count requirements (KDP Help; verify current values at upload time, they do change)
• Amazon KDP royalty structure — the 60%/50% split and the $9.99 US threshold, with per-marketplace equivalents
• The two rejections, the bleed bounding-box check, and the headless-Chrome media-query trap are from my own production log — measured, not estimated