EPUB 2 vs EPUB 3: What the Version Number Really Changes

A converted EPUB can look perfect on your laptop and lose its tables on a phone. That gap is not a rendering quirk. It is a version-profile decision made before the file was ever opened.

EPUB 2 vs EPUB 3 is a capability question, not a technical footnote. EPUB 3.0 superseded EPUB 2.0.1 in October 2011; the current line is EPUB 3.3, a W3C Recommendation dated 13 January 2026. Between those endpoints sits a markup change: XHTML 1.1 and DTBook give way to HTML5, bringing semantic structure, MathML, media overlays and accessibility metadata that the older profile simply cannot carry. Convert to an older target and those capabilities vanish quietly, surfacing later on a different reading system.

This post follows that chain: version history, the markup swap, what semantic structure buys you for headings, notes and navigation, tables and figures in reflowable flow, MathML and media overlays, accessibility metadata, reading system conformance, why EPUB 3.1 was skipped, and what the choice means for a PDF to EPUB conversion with toolkit.bot.

Why the Version Label Is a Capability Question, Not a Footnote

The version label in an EPUB's package document records which markup profile the content may use, not how the text looks on screen.

Two files converted from the same source PDF can hold identical words and read differently. One permits HTML5 semantics, MathML and accessibility metadata; the other does not. This article treats the choice as a capability question: what survives into the reading app, and what is removed before the reader ever opens the file.

Loss rarely shows at conversion time. It surfaces later as a flattened table, a heading that stops behaving as a heading, or a note that no longer links to its marker. Planning PDF conversion to EPUB around a version target matters for that reason, not for appearance.

The toolkit.bot position is that reflowable output should target EPUB 3, because the features that make a structured document behave have no earlier equivalent.

Version History in Brief: 2007 to the Current Specification

The version line starts earlier than most conversion workflows assume. Per EDRLab's version history, EPUB 2.0 was approved in October 2007, with EPUB 2.0.1 following in September 2010. EPUB 3.0 arrived in October 2011 and superseded 2.0.1. EPUB 3.0.1 followed in June 2014, EPUB 3.1 in January 2017 and EPUB 3.2 in May 2019.

The current line is EPUB 3.3, a W3C Recommendation dated 13 January 2026.

This timeline is why the file formats available at conversion time matter: everything before EPUB 3 defines less. What changed at each step, rather than when, is the subject of the comparison that follows.

The Markup Swap: XHTML 1.1 and DTBook Against HTML5

Beneath the version label sits a markup decision. EPUB 2 content documents are written in XHTML 1.1 or DTBook; EPUB 3 permits the XML flavour of HTML5 alongside more detailed semantic markup, as EDRLab's standards overview sets out. This is what changes in the EPUB at the file level.

HTML5 supplies sectioning elements, figure and figcaption, and a wider set of attributes that carry meaning rather than appearance. DTBook predates HTML5 semantics and is not used in current EPUB 3 authoring.

The practical difference is blunt. A heading marked up as a heading can drive navigation and text-to-speech; text merely styled to look bold is just text. Reading apps parse markup to decide what to do, so the target profile determines which hooks exist in the file at all. A capability omitted at conversion cannot be added back by the device that opens it.

What Semantic Structure Buys You: Headings, Notes and Navigation

Which hooks exist is one thing; what they buy is another. EPUB 3 semantic markup, expressed through epub:type and HTML5 elements, lets a conversion declare that a block is a heading, a note, a sidebar or a quotation, and a reading app can act on that declaration. A heading marked as a heading feeds the navigation tree; a heading that only looks bold does not.

EPUB 3 includes a navigation document that gives the reading system a structured table of contents. In a well-marked EPUB 3 file, a note reference can be linked to its marker; text placed at the foot of a page without markup cannot.

Screen readers and text-to-speech engines consume the same structural hooks, so semantics serve navigation and accessibility at once, though epub:type and ARIA attributes differ in purpose (EPUB Type to ARIA Role Authoring Guide). This matters most for journal articles and other long documents, where headings and notes carry the argument.

Where a reading app ignores a semantic element, the text renders but the behaviour does not.

Tables and Figures in a Reflowable Flow

Semantics carries similar weight for tables and figures. A reflowable layout forces a decision about what a table means once the screen is narrower than the original page, and EPUB 3 markup gives the converter more to work with.

A table captured as real table structure can be reflowed or scrolled by the reading app. One captured as running text or a bitmap cannot; it is a picture of a table, permanently sized. EPUB 3's figure and figcaption elements keep a caption tied to the image it describes rather than leaving it as a stray paragraph.

PDF conversion is where fidelity is decided. Multi-column pages, headers spanning columns and tables split across page breaks are the classic failure points, and they are also where a reflowable ebook file format either holds structure or loses it.

The features that let a table stay a table are defined in EPUB 3. Any loss is silent at conversion time and usually surfaces later, on a different device.

MathML and Media Overlays: Capabilities With No EPUB 2 Equivalent

MathML is EPUB 3 only. In a pre EPUB 3 target, an equation has to travel as an image or as plain text. An equation stored as an image has no semantic content and cannot be reflowed, searched or styled by the reading system.

Media overlays are listed in the EPUB 3 specification as a Rich Media feature with no counterpart in EPUB 2. EPUB 3 additionally permits manifest fallbacks, so a reading system can pick a rendering path it supports rather than failing outright.

Support stays optional, though. An app may ignore MathML or overlay audio completely, leaving the capability present in the file and absent on the device. That mismatch matters most where a single collection serves many different readers and devices, which is the everyday situation covered in library use cases.

Accessibility Metadata: What Gets Attached, and What Is Not Guaranteed

EPUB 3 defines accessibility metadata that describes what a publication offers: alternative text, structural navigation, and whether meaning depends on visual information. DAISY's reporting describes EPUB 3.3 and the EPUB Accessibility specification as widely adopted by commercial publishers and increasingly used for accessible format delivery.

The caveat is that metadata describes the file rather than certifying it. It can record that a publication is accessible; it cannot make a reading system honour the structure. The honest framing is that EPUB 3 gives a conversion somewhere to record accessibility information that EPUB 2 does not provide, and for publishers that record matters at submission: metadata and distributor submission.

A File Is Only as Useful as the App That Opens It

Metadata can describe structure, but rendering decides whether that structure appears. The EPUB Reading Systems 3.3 Recommendation, dated 17 October 2024, sets conformance requirements for applications that render EPUB files. It is a statement of what a conforming reading system should do, not a record of what Kindle, Kobo, BOOX, PocketBook, reMarkable or Supernote implement today. Anyone who uses it across those platforms needs that separation: a file can be correct and still lose behaviour on a particular device, which is why the version question and the device question stay apart.

Older reading systems may ignore HTML5 semantics, MathML or media overlays without reporting an error. The file opens, nothing looks broken, and a heading, equation or note simply does not behave. A specification sets an expectation, not an outcome. Test the finished file on the device you actually read on; that is the only way to know what survived.

Why EPUB 3.1 Was Skipped and Later Revisions Were Not

The reading app question has a counterpart in version history. EPUB 3.1 was declared defunct for lack of adoption; the Library of Congress notes that maintaining two versions of content cost more than the new version was worth. EPUB 3.2 (May 2019) and EPUB 3.3 (January 2026) followed a different approach, keeping the version root attribute at "3.0" and adding legacy features for backward compatibility, which is why they replaced 3.1 without repeating the break.

For anyone producing files, targeting EPUB 3.3 does not strand readers on earlier EPUB 3 systems the way 3.1 would have. Version labels inside EPUB 3 signal a compatible lineage, the opposite of the EPUB 2 to EPUB 3 jump. That contrast is settled at conversion time.

What This Means for a PDF to EPUB Conversion

The target profile determines which markup can be written, which metadata can be recorded, and which features exist for the reading app to act on at all.

The toolkit.bot position is that converting to a pre EPUB 3 profile leaves semantic markup, MathML and accessibility metadata with nowhere to be recorded. Nothing raises an error; the information simply has no element to live in.

Output fidelity still depends on the source PDF and the app you read on. Preview before committing a long document, and check the result on your own device.

Conclusion: Choose the Profile You Can Defend Later

Preview and device testing are not optional extras; they are how you verify a capability decision you already made at conversion time. Treat the EPUB version as that decision, not a label applied afterwards. Check the output is marked EPUB 3, then check the features you need are present: semantic headings that drive navigation, notes linked to their markers, tables retained as real table structure, and MathML wherever equations appear. A file can declare EPUB 3 and still fail these tests if the source was unclear or the reading app ignores the markup.

Test the finished file on the device you read on. A conformance specification describes what a conforming app should do, not what yours does.

When converting a PDF, target EPUB 3 so structure, math markup and accessibility metadata have somewhere to record themselves. Keep the source PDF beside the converted file, and re-check after firmware updates, since reading system behaviour shifts over time. The profile you choose now is the one you defend later, on whatever device you open next.