Fix Broken KDP Book Description HTML Before Amazon Sees It

Your KDP book description HTML can be perfectly sensible in a document and still look wrong on Amazon. The usual symptoms are obvious: readers see literal tags such as , bold text disappears, paragraphs collapse into one block, or KDP refuses to save the description at all.

Start by treating the description field as a limited publishing form, not a general web page. Strip out copied formatting, use only the tags Amazon currently permits, and check that every opening tag has a matching closing tag. That takes a few minutes and prevents a messy product page from becoming the first thing a potential reader sees.

The writing still matters most. But a strong hook loses force when it arrives as a grey wall of text, while raw code makes even a professional blurb look unfinished.

What breaks KDP book description HTML

Most description problems come from one of four places. Knowing which one you are dealing with makes the repair straightforward.

Rich-text formatting came along for the ride

Word processors, newsletter platforms, website builders, and AI chat windows often carry hidden formatting when you copy text. The visible result may look like ordinary bold or italics. Underneath, though, it can include style declarations, font instructions, spans, colour settings, nonbreaking spaces, or pasted links.

Amazon does not need, and will not reliably preserve, that extra markup. KDP may remove it quietly. It may show part of it as text. Or it may reject the field during validation.

A safer workflow is to paste your blurb into a plain-text editor first, then add simple Amazon-compatible formatting. If you are moving between several drafts, do not keep copying the already-formatted version back and forth. Keep one clean master version of the actual description copy.

The tags are valid HTML but not suitable for KDP

A browser accepts a huge range of HTML. KDP accepts a much smaller subset for book descriptions. That distinction catches authors who have used a website, email service, or sales-page template before.

For example, a description built with containers such as <div> or <section>, custom classes, font controls, tables, buttons, images, embedded media, or hyperlinks is not a good fit for the KDP description box. Even when a tag works somewhere else, Amazon may strip it or handle it differently across storefronts and devices.

Amazon’s permitted-markup guidance can change, so check its current help documentation when you are working on an important launch. In practice, keep the formatting modest: emphasis, short headings where appropriate, paragraph breaks, and simple lists for nonfiction. The more a description tries to behave like a designed landing page, the more likely it is to fail.

A tag is missing, mismatched, or nested in the wrong order

HTML tags work in pairs. Open bold with  and close it with . If you open italics inside that bold section, close italics first, then bold.

A vanished heir. An impossible debt. One last job.

That sequence is properly nested. This is not:

A vanished heir. One last job.

It is a tiny difference that becomes easy to miss after several rounds of edits. A single missing angle bracket or closing tag can affect everything that follows it.

Your preview and the live product page are not the same moment

KDP’s preview is useful, but it is not a guarantee that every Amazon storefront and Kindle app will display spacing in exactly the same way. Amazon can also take time to update the public detail page after you save changes.

Do not respond to that uncertainty by adding more code. Keep the markup simple, wait for the listing to refresh, then inspect the live page on a desktop browser and on a phone if possible. Focus on whether the opening lines, paragraph breaks, emphasis, and lists remain readable.

Use a small, reliable set of KDP description tags

For most fiction descriptions, you need very little HTML. A bold opening line, italics for a short quoted phrase or review line, and clear paragraph spacing are usually enough.

Amazon’s description editor has supported basic markup including bold and italic text, paragraph and line breaks, headings, and ordered or unordered lists. The exact allowed list is Amazon’s to define, so do not rely on an old forum post or a random HTML cheat sheet as your rulebook.

Use this as the practical approach:

Use ... or ... only for text that genuinely deserves emphasis.
Use ... or ... for light emphasis, titles, or a short line of dialogue.
Use ... to create distinct paragraphs.
Use   sparingly when a line break, rather than a full paragraph, is what you mean.
Use <ul> and <li> for a plain bullet list when it helps readers scan nonfiction benefits, included material, or series reading order.

Do not use a stack of tags merely to make a sentence feel important. Large blocks of bold text are harder to read, especially on a phone. Underlining can resemble a link, and excessive headings make a short blurb feel fragmented. Let the copy do most of the sales work.

A clean fiction description pattern

This pattern gives a reader an immediate hook, breathing room, and a clear conflict without turning the description into a wall of text:

The rescue mission was meant to be simple.

When pilot Nia Calder lands on an abandoned moon station, she finds one survivor, no rescue beacon, and a logbook written in her own handwriting.

To get home, Nia must decide whether the person asking for her trust is an ally, a future version of herself, or the reason the station was sealed.

Notice what is absent: no font names, colours, alignment instructions, links, symbols used as fake bullets, or decorative dividers. The description will still have shape when Amazon presents it in a narrow mobile layout.

A clean nonfiction description pattern

Lists can be useful when the promise of the book has several concrete parts. Put a brief setup before the list and a reason to buy after it. Do not turn the entire description into bullets.

Build a weekly meal plan without spending Sunday night doing admin.

Inside, you will find:

<ul>

<li>ten repeatable planning templates</li>

<li>shopping lists for common dietary needs</li>

<li>a four-week reset for busy households</li>

</ul>

Use the system as written or adapt it to the food your family already enjoys.

Write the list items in parallel. If the first begins with a verb, make the others begin with verbs too. That is a copywriting detail, but it also makes a product page easier to scan.

Fix a broken description without rewriting the blurb

When Amazon has stripped or mangled formatting, resist the temptation to edit directly inside the KDP field until it looks right. Repeated edits can make the underlying markup harder to inspect. Instead, work from a clean copy outside KDP.

Copy the current description into a safe working document.
Make a plain-text copy of the wording so you can preserve the blurb even if you remove all markup.
Delete unsupported layout code, pasted links, styling attributes, and unusual copied characters around the HTML.
Choose only the formatting that improves scanning: a hook, paragraph breaks, and perhaps one short list.
Check every opening tag against its closing tag. Search for < and inspect each result if necessary.
Paste the cleaned version into KDP’s HTML editing option, then use the preview before saving.

Pay special attention to copied review quotes and series promotion. A review source may include curly quotation marks, a long dash, or a trademark symbol, which are usually fine as text. The trouble starts when its web formatting comes too: linked reviewer names, styled spans, or a pasted block from an email signature.

Also separate formatting errors from content-policy issues. A description can have valid markup and still be flagged for prohibited claims, misleading pricing language, excessive keyword repetition, customer-review material that breaches Amazon’s rules, or content Amazon does not allow in metadata. An HTML cleanup will not solve those problems. It simply removes one avoidable cause of a delayed update.

Check the markup before opening KDP

The quickest safeguard is to run the final version through a purpose-built validator before submission. Pendrilo’s free KDP description checker works in the browser and checks the 4,000-character limit as well as filtering description markup against allowed rules. Paste in the final text, review the flagged markup, and copy a clean version into KDP.

This is particularly useful when you have combined a blurb from a designer, a launch assistant, an older edition, and your own edits. Each source can add a slightly different kind of formatting. The visible text may look identical while the code is not.

For authors who want their listing details beside the manuscript, Pendrilo’s KDP workflow includes a Description step with an Amazon-style preview, character limit, and draft-versus-live versioning. You can try the full studio with a seven-day trial; it includes one book and up to 3,000 cumulative words, with no card required.

A final check that catches most Amazon display problems

Before you save the description in KDP, read it once as a reader rather than as the person who wrote it. The first two lines should make sense without formatting. Paragraphs should be short enough for a phone screen. Bold should point to the promise, not compensate for a vague one.

There is no pasted Word, web-page, or email styling in the code.
Every tag is on Amazon’s current allowed list.
Opening and closing tags match and nest correctly.
Paragraphs use real paragraph markup rather than a run of empty spaces.
Lists are used only where they improve clarity.
The description remains under KDP’s 4,000-character limit.
The KDP preview and live listing have been checked after the update processes.

A clean KDP description does not need clever HTML. It needs restrained markup that survives Amazon’s rules and keeps the reader moving from the hook to the buy button.