EPUB 3.4: What Publishers Should Change, Validate, and Leave Alone

Understand the EPUB 3.4 draft, test new features, validate with EPUBCheck 5.4.0, and decide what to change or preserve in existing ebooks.

Publishing Standards Editorial Staff
October 16, 2026
21 minutes

Sources checked October 16, 2026, Central time.

A production editor opens an EPUB that passed its previous release checks. A newer validator now reports legacy features, while a standards announcement promises vertical comics and new image formats. The immediate question is practical: does the publisher need to rebuild the book, change its metadata, or stop distribution?

For most established titles, the first job is to review evidence before changing files. W3C's October 12 announcement explicitly emphasizes backward compatibility for previously conforming EPUB publications. Its new features create opportunities for selected projects, rather than a reason to convert an entire catalog. W3C announcement

The short answer: EPUB 3.4 remains a draft on the W3C Recommendation track. Publishers should update their validation workflow, pilot relevant features, investigate diagnostics, and retain separate accessibility and distribution checks. A validator pass does not establish that a retailer accepts a file or that every reader can use it.

The workflow below is Publishing Standards' operational recommendation. It distinguishes verified specification and software changes from the production decisions a publisher must make.

What is final, and what is still being tested?

The latest published EPUB 3.4 document checked for this article is a Candidate Recommendation Draft dated October 2, 2026. It is work in progress, not a completed W3C Recommendation. The EPUB 3.3 specification remains a published Recommendation.

Three documents have different jobs: EPUB 3.4 addresses publications, EPUB Reading Systems 3.4 addresses the software that presents them, and EPUB Accessibility 1.2 addresses accessibility and discoverability. W3C's July 21 implementation invitation requested comments by October 19, 2026. That is a feedback date, not a publisher conversion deadline.

Item	Verified position	Production consequence
EPUB 3.4	Candidate Recommendation Draft, October 2	Identify the draft when documenting tests or discussing new requirements.
EPUBCheck 5.4.0	Production-ready software release, September 15	Pilot the validator upgrade and retain versioned reports.
Existing conforming EPUBs	W3C affirms backward compatibility	Review actual defects and channel needs before rebuilding.
New layouts and media	Added to candidate-stage specifications	Test each proposed use in the intended delivery environment.
October 19 feedback date	Implementation-review milestone	Submit reproducible findings where useful; do not treat it as a sales cutoff.

The distinction matters when commissioning conversion work. A supplier's statement that a book is “EPUB 3.4 ready” should lead to a concrete question: what file was checked, with which software, against which document, and on which reading systems?

What EPUB 3.4 changes in practice

Roll layouts give vertical comics a defined layout model

The draft adds roll as a rendition:layout value for fixed-layout content. The reading-system draft says supporting readers fit spine items to viewport width and present them continuously without visible gaps. Support for roll rendering is a SHOULD, not a universal implementation guarantee. EPUB Reading Systems 3.4

For a comics publisher, the useful pilot is a representative episode. Include transitions between documents, dialogue at realistic phone sizes, a long sequence, and navigation back to an earlier section. Ask testers to reopen the book after leaving midway through an episode. Record clipping, unexpected spaces, slow image loading, and lost reading positions.

A prose publisher generally has a different decision. If a novel or business book works well as reflowable text, retain that reader benefit. A new layout option should answer a content need. Converting adjustable text into fixed images merely to use a new feature creates production work without an established reader benefit.

New media support expands options, not channel guarantees

The official EPUBCheck 5.4.0 release adds checks for AVIF and JPEG XL and for Opus and AAC codecs in MP4. The container detail matters: “Opus support” is not permission to package every possible Opus file arrangement.

Before changing an image workflow, compare a sample against the current output. Look at fine lettering, gradients, transparency, illustrated text, and decoding behavior on the actual devices used for review. Record file size and visible quality together. Smaller output is useful only if the book remains readable through delivery.

Retain source artwork and the previous export settings. If a distributor cannot handle the pilot, the team should be able to generate a channel-appropriate file without reconstructing the book. Ask the distributor about its current ingestion and conversion process rather than inferring acceptance from the format specification.

Accessibility metadata needs a working support process

The EPUB Accessibility 1.2 draft includes a11y:contactEmail, an optional publication-level property for accessibility questions and issue reports. It takes an email address, is limited to zero or one occurrence, and must not use refines.

Adding a contact field is a small technical change. Making it useful requires assigning someone to monitor the mailbox, associate reports with the correct file, and arrange corrections. Metadata should describe the delivered publication and the support readers can actually obtain.

This article does not replace our EPUB Accessibility 1.2 publisher release checklist. Use that companion for the broader accessibility evaluation and evidence process. Here, the immediate task is to connect the newly recognized metadata to an accountable production workflow.

Outdated and deprecated features require different responses

W3C distinguishes outdated features, discouraged for new work but retained for compatibility, from deprecated features with little support. Its examples include outdated font obfuscation and deprecated epub:switch. W3C explanation

The EPUBCheck change log identifies new usage notices for such items as OPF 2 NCX, the legacy guide, prefixed CSS properties, and font obfuscation. A compatibility aid in an older book should be investigated before removal.

For new templates, review whether legacy output is still necessary. For backlist files, ask whether changing it fixes a demonstrated problem, satisfies a documented channel requirement, or reduces a maintenance burden enough to justify a new release. Keep font licensing conditions in view when considering changes to embedded fonts.

What publishers should leave alone

Do not change the package document to version="3.4". The EPUB 3.4 draft still requires version="3.0" for EPUB 3 package documents. Specification revisions within EPUB 3 do not require that attribute to follow the document title. Package document requirements

Also avoid replacing stable identifiers, renaming all chapter files, or restructuring a functioning book merely to signal that someone reviewed the new specification. Those changes complicate comparison and troubleshooting. When a correction is necessary, record its scope and preserve the preceding release.

Separate a standards review from a commercial edition decision. Whether a content revision warrants a new edition or identifier is a different question from whether a validator now recognizes a layout or metadata field. Our guide to the hidden publishing system provides the wider production context.

How to validate an EPUB with EPUBCheck 5.4.0

1. Obtain the official distribution and identify the runtime

Download the binary ZIP from the official v5.4.0 release page. Extract the complete archive. Keep epubcheck.jar beside its supplied dependencies, including the lib directory. The official installation guide documents running the JAR through Java.

Open PowerShell on Windows, or a terminal on macOS or Linux. Change to the extracted directory containing epubcheck.jar, then run:

java -version
java -jar epubcheck.jar --version
java -jar epubcheck.jar --help

Confirm that EPUBCheck identifies itself as 5.4.0. Use a maintained Java runtime approved for your workstation and confirm that this distribution starts successfully. A graphical application or package-manager installation may include a different validator version, so check the version actually used.

At verification time, W3C's separate releases index still headed its list with 5.3.0. The dated GitHub release and repository change log establish the newer release. The inconsistency should be recorded, without treating a stale index as evidence that 5.4.0 is experimental.

2. Validate the packaged file that will be delivered

The commands below assume the JAR and a copy of publication.epub are in the current directory. Replace the sample filename with your book's filename. Quotation marks preserve paths containing spaces.

java -jar epubcheck.jar "publication.epub"

Keep the candidate file unchanged while reviewing its report. If the export process changes it afterward, validate the resulting file again. A checked working folder and a later packaged download are different artifacts until the team establishes otherwise.

3. Expose usage notices and retain a complete JSON report

java -jar epubcheck.jar "publication.epub" --usage --json "publication-epubcheck-5.4.0.json" --maxOfEachMessage unlimited

These switches are documented in the official command-line reference. --usage exposes informative diagnostics hidden in normal output. --json writes a structured report; --maxOfEachMessage unlimited removes the normal repeated-message cap for structured output.

Name reports so the title, candidate revision, and tool version remain clear. Store them with the corresponding EPUB and production notes. A report without an identifiable input file is weak release evidence.

4. Interpret messages before assigning remediation

The message reference distinguishes fatal errors, errors, warnings, information, and usage messages. Errors identify conformance failures; warnings concern recommended practices. Usage notices are informational. The new outdated-feature diagnostic is a usage notice.

Result	Recommended publisher action
Fatal error or interrupted run	Resolve the cause and rerun; do not record the attempt as a completed pass.
Error	Correct the identified conformance failure and validate the rebuilt EPUB.
Warning	Investigate the recommendation, reader impact, and channel policy; record the decision.
Usage notice	Review relevance and legacy dependencies before changing the book.
No reported errors	Continue accessibility, reading-system, editorial, and delivery review.

For example, a missing resource calls for repair. A notice about a legacy navigation mechanism calls for a compatibility decision. Assigning both the same “must remove” instruction can damage a functioning title.

5. Decide whether warnings should block an automated release

java -jar epubcheck.jar "publication.epub" --failonwarnings

By default, warnings alone do not produce the error return status. --failonwarnings makes warnings return status 1 as well. It does not turn usage notices into warnings. The -v option concerns single-file checking modes; it is not a -v 3.4 upgrade switch for a packaged EPUB. CLI reference

For manual runs, inspect the completed output and report. For automated builds, capture the process result immediately and stop the release when the adopted policy requires it. Investigate unexpected Java or command-launch failures separately. Do not let a later successful command conceal a failed validation attempt.

6. Fix the source, rebuild, and check again

Correct recurring defects in the production source or export template whenever possible. A repair applied only inside the final ZIP can disappear on the next export. Keep a brief correction record connecting the diagnostic, the source change, and the new report.

If the supplier and publisher obtain different results, first compare the EPUB files and validator versions. Then compare command options. That small reconciliation step can prevent hours of argument about reports produced from different inputs.

A pass is one part of release approval

Use three separate questions in the approval record. Is the package structurally conforming under the recorded check? Can readers navigate and understand it using the intended accessibility features? Does the distribution channel accept and deliver a usable version?

For a new layout or media pilot, test the book both before upload and through any available channel preview or delivered output. Include the table of contents, internal links, orientation changes, reopening, text or panel legibility, and the content near document boundaries. Record the application, version, operating system, and test date.

Accessibility review should include the real reading sequence and meaningful alternatives for visual information. A technically accepted comic that exposes dialogue in the wrong order can still fail readers. Keep that evaluation attached to the same candidate file as the validator report.

Do not label a validator result “retailer approved,” “universally compatible,” or “fully accessible.” Each of those statements requires evidence beyond a package check. Use precise wording: “Checked with EPUBCheck 5.4.0 on [date], report retained,” followed by the separate test outcomes in the internal release record.

A practical rollout for a small publishing team

Start with a small test shelf: a straightforward reflowable title, a heavily illustrated title, a book containing legacy navigation or fonts, and a candidate using a new feature. Add a media-overlay title if the catalog contains one. Choose examples that exercise the workflow rather than selecting only the easiest books.

Run the previous and new validators on the same copies. Compare diagnostics, classify new findings, and identify which ones originate in shared templates. Update those templates in a controlled branch or working copy, then re-export the sample titles. Review the results before changing the default production pipeline.

Release record field	Evidence to retain
Candidate identity	Filename, internal revision, and preferably a checksum
Validation	Tool version, command options, date, report, and completed-run result
Findings	Severity, affected files, owner, correction or documented decision
Reader testing	Application and OS versions, tested actions, and observed results
Accessibility	Evaluation record and substantiated metadata claims
Distribution	Channel response and review of available converted or delivered output
Approval and recovery	Approver, release date, retained prior file, and rollback procedure

This record extends the site's established emphasis on documented publishing decisions. Issue 003 addressed other records, including annotation-related edition stability. The present guide adds file-validation evidence without retelling those earlier developments.

Set priorities by reader impact and release timing. Repair active defects first. Improve templates before the next scheduled export. Pilot new features where they serve the publication. Revisit stable backlist files when evidence establishes a reason to change them.

Questions publishers are asking

Is EPUB 3.4 a finalized standard?

No. At this article's verification date, its latest published document is the October 2, 2026 Candidate Recommendation Draft. Recheck W3C's document status before making later claims about finalization.

Do all existing ebooks need conversion?

W3C affirms backward compatibility for conforming publications. Review defects and specific delivery requirements rather than commissioning a blanket rebuild.

Does a usage notice mean the EPUB failed?

No. It is informational. Read the message and document the appropriate response; do not confuse it with an error.

Can EPUBCheck prove accessibility or retailer acceptance?

No. Retain separate accessibility evaluation, reading-system testing, and distribution evidence.

What should a publisher do before October 19?

If testing reveals a relevant specification or implementation problem, submit useful evidence through W3C's linked issue tracker. Include the specification section, expected behavior, actual behavior, and a minimal example you have permission to share. The review date does not require a catalog conversion.

The next release decision

Assign one production owner to introduce the validator, retain the first comparison reports, and bring unresolved findings to the release review. Give new layouts and formats a documented pilot. Preserve established files where there is no demonstrated reason to replace them. The useful result of this standards update is a production process that can explain why each book is ready to ship.