The CSS that actually survives Kindle, why it breaks on devices but not in Previewer, and when to skip drop caps entirely
To add a drop cap to an ebook, wrap the chapter's first letter in a <span>, float it left at roughly 3× the body font size with small negative margins, and add an @media amzn-kf8 adjustment for Kindle — this floated-span technique is the one Amazon's own KDP guidelines document. Use relative units (em, %) only, and remove the first paragraph's indent. On Kindle, treat that CSS as a suggestion: the Enhanced Typesetting engine detects the pattern and re-typesets the cap itself, so the result flexes with the reader's font and settings.
Most guides on this topic are either a tool walkthrough (Jutoh, Kindle Create, Vellum) or a bare CSS snippet with unexplained magic numbers. This one comes from the people who generate the file: we build EbookFormatter's EPUB generator, and drop caps are one of its built-in chapter-opening styles — so below is the exact CSS we ship in every generated book, what each value is for, and the failure modes we've had to design around.
A drop cap is an enlarged first letter that drops below the first line, with the next two or three lines of text wrapping around it. It's the oldest chapter-opening device in the book — enlarged initials (also called versals) go back to roughly the fourth century, and they started as navigation, marking where sections began in manuscripts that had no paragraph spacing. Gutenberg's press left blank squares so a rubricator could paint the initials in by hand afterward.
Two related styles matter here because they're the standard fallbacks when a drop cap is more trouble than it's worth:
font-variant: small-caps needs an EPUB3-era renderer — it fails in old Adobe Digital Editions engines, including the one Kobo uses for plain sideloaded .epub files.)All three exist for the same reason a scene break ornament does: they're typographic signals of structure. The difference is that a drop cap is the only one that depends on layout — floating, wrapping, aligning — and layout is exactly the thing a reflowable ebook doesn't let you control.
If you're writing your book in markdown, your manuscript needs nothing at all — no span, no class, no HTML. A chapter is just:
# Chapter One
The letter arrived on a Tuesday, which was somehow worse.When EbookFormatter converts the file, choose Drop Cap as the chapter-opening style (the Serif theme turns it on by default; Large Cap and Small Caps are right next to it). The converter finds each chapter's first paragraph, wraps the opening letter, applies the tested CSS below, and removes that paragraph's first-line indent — the same flush-left convention that applies to the paragraph after a scene break. One detail worth knowing: if your chapter opens with a blockquote epigraph, the generator skips it and puts the drop cap on the first real paragraph of prose, not on the quotation.
Here is the drop-cap CSS EbookFormatter ships inside every generated EPUB (plus one line we apply separately: the cap is tinted with whatever accent color you pick for the book):
.dropcap {
float: left;
font-size: 3.4em;
line-height: 1.1em;
padding-right: 0.05em;
margin-bottom: -0.6em;
font-weight: bold;
overflow: hidden;
}
@media amzn-kf8 { .dropcap { margin-top: -0.25em; } }
@media amzn-mobi { .dropcap { margin-top: -0.25em; } }applied to markup shaped like this, with the paragraph's indent removed:
<p class="no-indent"><span class="dropcap">T</span>he letter arrived
on a Tuesday, which was somehow worse.</p>Every value is doing a job:
float: left is what makes it a drop cap at all — the letter leaves the line and the following text wraps around it. It's also the pattern Kindle's engine looks for (more on that below).font-size: 3.4em — sized in em so the cap scales when the reader changes font size. Amazon's KDP guidelines are explicit that drop caps must use relative units, never px or pt; a pixel-sized cap stays fixed while the body text grows, and the design collapses. Around 3× body size yields a cap roughly three lines tall.line-height: 1.1em and margin-bottom: -0.6em — the alignment knobs. A floated letter brings its own line box, which is taller than the glyph; tightening the line-height and pulling the bottom margin negative closes the gap so wrapped lines tuck under the letter instead of leaving a moat. These numbers are font-metric-dependent — ours are tuned against the typography our themes ship, which is why snippets copied between books with different fonts so often sit wrong.@media amzn-kf8 — an Amazon-documented media query that applies only on Kindle's KF8 path. The extra margin-top: -0.25em pulls the cap up so its top aligns with the first line of body text, which is exactly the alignment KDP's guidelines ask for. Amazon's own published sample does the same job with values of -0.3225em at font-size: 320% — hand-tuned compensation, same as ours, different font assumptions.overflow: hidden — keeps deep descenders and swash tails from painting outside the float's box and colliding with the next paragraph.@media amzn-mobi — the query for legacy MOBI-era devices, which can't float reliably. Amazon's documented fallback there is to give up on the drop and render a simple large bold letter (font-size: 3em; font-weight: bold) — a raised cap, in other words, which is the honest best those devices can do.If you're hand-building your EPUB (with Pandoc, say, after converting markdown to EPUB yourself), that block plus the span is the whole recipe. The point of listing the reasons is that you'll almost certainly need to nudge the numbers for your font — now you know which knob moves what.
This is a recurring complaint on the KDP forums, and the answer is a mental model no snippet ever comes with: Kindle does not render your drop-cap CSS — it detects the pattern and rebuilds the cap with its own engine.
Amazon's Enhanced Typesetting engine (the KFX format, introduced in 2015) converts your EPUB by rendering it, extracting the computed styles, and re-encoding the book in Amazon's own format. Ebook developers who have reverse-engineered the pipeline — Jiminy Panoz's teardown of the KFX conversion process is the classic writeup, and the developer of the KFX conversion tools has confirmed the same on MobileRead — found that when the engine sees a floated first element with a larger font size, it classifies it as a drop cap and replaces your styling with an internal representation that has only two parameters: how many leading characters to include, and how many lines tall to make it.
Once you know that, the classic complaints explain themselves:
The practical consequences: keep the markup boringly canonical (one span, one letter, floated — the exact pattern Amazon documents), because unusual cleverness confuses the detector; never float anything else near a chapter opening at a larger font size, or the engine may "drop cap" content that isn't one; and test in three places — Kindle Previewer 3, the KDP online previewer after upload, and a real device — at more than one font size. Enhanced Typesetting is applied automatically when a book qualifies; there's no documented way to opt out. One more Kindle-specific trap from the KDP forums: authors using Kindle Create report that its "export as EPUB" can change a drop cap's line count (a two-line cap becoming three), so if you build in Kindle Create, upload its native .kpf file rather than the exported EPUB.
The same CSS travels reasonably well beyond Amazon, with one structural surprise on Kobo: it runs two different rendering engines, chosen by file extension. A plain .epub is rendered by Adobe's RMSDK — an engine frozen around 2013, with correspondingly old CSS support — while a .kepub.epub gets Kobo's maintained WebKit renderer. Identical CSS, different results, purely by filename. Apple Books runs WebKit, where the floated span is ordinary web CSS, though the newer initial-letter route needs its -webkit- prefix there. The float-span technique's virtue across all of these is that it's plain, old CSS: a float either works (you get a drop cap) or degrades (you get a slightly odd large letter) — it doesn't take the page down with it.
There are three ways to mark a drop cap in CSS, and each has exactly one serious flaw:
| Technique | How it works | The catch |
|---|---|---|
Floated <span> |
Wrap the letter, float it. The technique Amazon's KDP guidelines document, and what EbookFormatter generates. | Screen readers can pronounce the wrapped letter separately from its word — "T… he" instead of "The." The DAISY accessibility knowledge base flags exactly this. |
::first-letter |
Pure CSS, no extra markup — which is why DAISY calls it currently the most accessible option. | Rendering is inconsistent across reading systems, and by spec it drags adjacent punctuation into the selection — an opening quote gets enlarged along with (or instead of) the letter, and engines disagree on the details. |
initial-letter |
The purpose-built CSS property: you say "three lines tall" and the engine handles sizing and baseline alignment. The correct long-term answer. | Still a W3C Working Draft with partial support — no Firefox support at all, prefix required in Safari, and it appears nowhere in Amazon's documentation. Usable only as a progressive enhancement in 2026. |
We chose the floated span with eyes open: it's the only pattern Amazon documents, and Kindle is where most self-published books are read. But the accessibility cost is real, so if your audience skews toward screen-reader or text-to-speech use, weigh the small-caps opening instead — it has no such problem, and it's one click away in the same setting.
Here's the failure nobody warns you about until chapter twelve opens with dialogue:
"When were you going to tell me?"What should the drop cap be — the quote mark, or the W? There is no good answer, and on Kindle there isn't even a choice: the KFX drop-cap model counts leading characters and has no mechanism for styling punctuation differently from the letter. Ebook developers on MobileRead have documented the fallout for years — it's especially painful in Spanish, where dialogue opens with an em-dash. The three workable options, in rough order of sanity:
Many professional ebook designers leave drop caps out of the EPUB edition even when the print edition has them — one 2026 formatting guide puts it flatly: most ebook designers skip drop caps or use raised initials instead. The reasons are all things you've now seen: the reader controls font, size, and line spacing, so no floated-letter design can be guaranteed, and the long-running consensus among MobileRead's power users is that a drop cap can't be made to look right against every font and line-height combination a reader might choose. Skip them without guilt when:
The good news: this isn't a build-it-yourself decision. All three chapter-opening styles are single options in the same menu, so trying your book both ways costs about a minute — pick a style, convert, and flip through the chapters in your structured manuscript on whatever device you own.
Yes — Amazon documents the floated-span technique in its own KDP guidelines, and Enhanced Typesetting lists drop caps as a supported feature. But Kindle re-typesets the cap with its own two-parameter engine rather than rendering your CSS, so the result flexes with the reader's settings and is never pixel-guaranteed.
Previewer, the KDP online previewer, and devices rebuild your drop cap independently through Enhanced Typesetting's detection heuristics, so they can disagree. Test in all three, at more than one font size, before publishing.
A floated span at roughly 3× body size with tightened line-height and small negative margins: float:left; font-size:3.4em; line-height:1.1em; margin-bottom:-0.6em; plus an @media amzn-kf8 block pulling margin-top negative so the cap's top aligns with the first line. Relative units only.
Let the quote and letter drop together as a two-character cap, rewrite the opening so it doesn't begin with dialogue, or use a raised cap or small-caps opening for that book. Kindle's engine can't style leading punctuation separately, so there's no CSS fix.
The span-wrapped technique can cause screen readers to pronounce the first letter separately from its word — a problem documented by the DAISY accessibility knowledge base. ::first-letter avoids it but renders inconsistently in ebooks. If accessibility matters for your audience, prefer a small-caps opening.
A raised cap (enlarged first letter on the baseline — nothing floats, nothing misaligns) or a small-caps opening line. Both are traditional, both signal the chapter opening, and both are immune to the rendering problems above.
Want the drop cap without the CSS? Write your chapters in plain markdown, then format your book — pick Drop Cap, Large Cap, or Small Caps and get a Kindle-ready EPUB in seconds, no account needed. New here? Start with the Formatting Guide or browse our guides.