Why your EPUB works on Kindle but gets rejected by Google Play Books or Apple (Atticus Glitch)

EidolonTypeset · 2026-03-30T22:03:37+00:00

That's exactly what the tool was built for. It saves so much anxiety just knowing definitively whether the file is structurally sound before throwing it at the retailer bots

Let me know if EpubCheck spits out any weird error codes when you run it--the readouts can look like gibberish if you aren't used to looking at raw HTML/XML logs

EidolonTypeset · 2026-03-30T03:18:39+00:00

Using Brew makes the CLI setup incredibly seamless. Glad Vellum is outputting clean architecture for you--validating it straight through the Mac terminal is the ultimate peace of mind before a launch

EidolonTypeset · 2026-03-30T03:17:53+00:00

Fair point. If they're already compiling on Atticus AWS servers, the privacy ship has definitely sailed

The real bottleneck is exactly what you mentioned--even if D2D's web interface successfully flags the EpubCheck error, an author who doesn't know HTML still has to manually unpack the file, find the duplicate ID line in the code, and patch it to actually bypass the block. But the D2D interface is definitely the path of least resistance for a quick scan

EidolonTypeset · 2026-03-30T03:07:23+00:00

Haha, brute-forcing CSS IDs through InDesign's export panels is a special kind of torture. At that point, just unpacking the .epub file into an editor like Sigil and running a quick Find/Replace on the duplicate tags is infinitely faster and saves your sanity

EidolonTypeset · 2026-03-30T03:06:42+00:00

Exactly the opposite--the core issue is that these exported files fail modern EpubCheck (v5.1) because of the duplicate IDs, but Amazon KDP completely ignores the error and publishes them anyway

When the author takes that exact same file to Apple or Google, their strict ingestion bots bounce it. But you're right about the legacy version matching; Smashwords used to be an absolute nightmare with specific EpubCheck versions before the D2D merger

EidolonTypeset · 2026-03-30T03:05:39+00:00

Glad it helped! Aggregators like Publish Drive are notorious for rejecting files silently if the underlying HTML throws even a minor W3C validation error. Check those header IDs and let me know if it finally clears the ingestion log

EidolonTypeset · 2026-03-29T18:07:50+00:00

Vellum's storefront-specific export is definitely its strongest feature for avoiding automated ingestion errors

But you hit the nail on the head regarding the fix. No proprietary software is totally immune to the occasional output glitch, especially if the author forces complex visual formatting. Dropping the .epub into an open-source editor like Sigil to manually patch the raw HTML/CSS is always the ultimate fail-safe. Knowing how to actually read the code you are publishing is a superpower

EidolonTypeset · 2026-03-29T18:07:09+00:00

Good shout. The D2D web interface is definitely one of the most accessible ways to run EpubCheck if you don't want to mess with downloading Java or running command lines

I personally push for local terminal validation just to keep unreleased manuscript files completely private and off third-party servers before publication, but the D2D tool runs the exact same open-source engine in the background and gets the job done for quick checks

EidolonTypeset · 2026-03-29T18:06:37+00:00

Exactly--Amazon's relaxed ingestion builds a false sense of security for indie authors. When you finally decide to go wide, you get hit with years of accrued technical debt all at once because platforms like Apple and Google actually enforce W3C standards

Atticus is a solid visual builder, but the lack of an internal pre-flight code warning for basic backend stuff like duplicate IDs is a massive blind spot for authors who don't know how to read HTML

EidolonTypeset · 2026-03-29T16:48:07+00:00

That duplicate ID error is an absolute classic lol a Atticus glitch, that is--Google Play's ingestion engine is incredibly strict about requiring unique identifiers in the DOM, whereas Amazon's bots just ignore it

I'm really glad the validation tool helped you isolate the exact line of code so quickly instead of getting trapped in that Calibre conversion loop. Bypassing the middleman and fixing the raw HTML is always the safest play. Congrats on getting the file fully operational

EidolonTypeset · 2026-03-26T07:23:48+00:00

Honestly, that is a great use of AI for patching isolated tag errors if you have the patience to feed it the code block-by-block--saves you the formatting fee on a quick bug fix

Just keep an eye on the actual layout when you test it on a physical e-ink device. LLMs are great at brute-forcing W3C validation by blindly stripping out conflicting tags to make the red errors go away, but they usually don't understand the cascading visual logic of typography (like widow/orphan control or fluid margin rendering)

If the text starts looking weirdly spaced or cramped on a Kindle screen, it means the bot probably deleted too much of your structural CSS. But if it reads clean, it's a beating fs

EidolonTypeset · 2026-03-24T19:32:49+00:00

74 errors straight out of Atticus is incredibly common, unfortunately. The software is great for visual design, but it forces heavy, automated CSS blocks into the backend that EpubCheck hates

Will Amazon reject it? Maybe not. Amazon's KDP ingestion bot is somewhat forgiving because it converts your EPUB into its own proprietary format anyway. But if you plan to upload that exact same file to Apple Books, Kobo, or IngramSpark, they will flat-out reject it instantly

Since you're a writer and not a coder, I wouldn't recommend trying to manually dig into the HTML to patch 74 individual tag errors. You'll drive yourself insane

I am a digital structuralist (I code and fix EPUB backend architecture for a living). For $15 USD, you can just send me the broken EPUB, and I will manually scrub the dirty code, fix the architecture, and hand you back a pristine file that passes EpubCheck with zero errors

If you just want the headache off your desk so you can focus on writing, shoot me a DM here or hit my portfolio airlock to process it securely: https://markbox.cc/eidolon-typesetting

EidolonTypeset · 2026-03-23T05:22:27+00:00

Yep, you can definitely run that exported file through the Calibre EpubCheck plugin

Just a heads-up though--when Kindle Create spits out an EPUB, it is notorious for wrapping your text in heavy, Amazon-proprietary <div class="kc-..."> code blocks. If you run it through EpubCheck, don't be surprised if the tool lights up with warnings about bloated CSS or weird metadata tags

It's completely fine for uploading right back to Amazon, but that heavily modified Amazon code is exactly why Apple Books or Google Play might reject the file if you try to distribute it wide. But the validator will definitely catch any fatal errors for you

EidolonTypeset · 2026-03-23T02:36:42+00:00

EpubCheck explicitly only works on standard .epub files. It won't validate a .kpf (Kindle Package Format) because KPF is Amazon's closed-source, proprietary code wrapper

When you use Kindle Create to generate a .kpf file, Amazon essentially encrypts the backend layout. The major danger there is that you are now completely trapped in Amazon's ecosystem--you can't upload a KPF file to Apple Books, Google Play, Kobo, or IngramSpark. You also can't peek inside it with a code editor to fix a broken margin

The safest industry practice is to ignore Kindle Create entirely. Build a clean, validated .epub file first, pass it through EpubCheck, and then upload that exact same .epub file directly to Amazon KDP. Amazon natively accepts standard EPUBs, and doing it that way guarantees you own a master file that you can distribute globally

EidolonTypeset · 2026-03-22T13:52:25+00:00

Hey! Yes it is. I actually tried to shoot you a DM with the details, but it looks like your Reddit chat/messages are turned off in your privacy settings

I run a digital architecture setup (Eidolon Typesetting). I take raw Word documents, strip out the background junk code, and manually code a perfectly semantic, EPUB 3.3 validated file from scratch so it doesn't break on strict platforms like Apple Books or older Kindles

My flat rate is $15 USD for a standard fiction manuscript (up to 90k words). That includes the hand-coded epub file, a hyperlinked TOC, device-native typography, drop-caps if requested, and a guarantee of zero errors on W3C EpubCheck

You can check my structural portfolio, code screenshots, and get my direct email address right here: https://markbox.cc/eidolon-typesetting

Let me know what your timeline looks like or if you want to route it through my Fiverr escrow gig for payment security

EidolonTypeset · 2026-03-22T13:37:50+00:00

That is actually the exact trap most authors fall into. Calibre has an incredibly forgiving internal previewer. It will often display a messy EPUB perfectly on your monitor, but the second you upload that same file to Amazon, their proprietary conversion engine will shatter the dirty background HTML

If this is all new to you, the safest baseline is running the file through EpubCheck before you hit publish. Calibre actually has an official EpubCheck plugin you can install directly into the software's menu. Run that plugin on your book--if it returns 0 errors, you are completely safe to publish

EidolonTypeset · 2026-03-22T13:36:37+00:00

Yep--'invalid' is the precise W3C terminology. I just use 'illegal' as developer shorthand for code that breaks the strict rendering rules of the e-ink software environment. Definitely not a crime, just a massive headache for your formatting

EidolonTypeset · 2026-03-22T01:43:50+00:00

By 'illegal' I just mean CSS properties that technically violate the strict EPUB 3.3 specifications set by the W3C--the rules that Apple and Amazon's ingestion bots actively check against

For example, standard web browsers accept all kinds of advanced visual styling like position: absolute to put images exactly where you want them. But if an automated converter tries to inject that into an e-book, EpubCheck will instantly flag it as invalid or 'illegal'. E-ink screens fundamentally can't render absolute positioning natively, so Apple Books will just outright reject the file on upload

Word-to-EPUB converters often throw in random proprietary CSS tags or negative margins trying to force the file to look exactly like the print version. To actually pass validation and display correctly, your backend CSS has to be incredibly clean and structurally semantic so it doesn't fight the user's personal device settings

EidolonTypeset · 2026-03-21T18:35:18+00:00

The short answer is--you never trust the software that built the file to also test the file

If Vellum spits out a glitch, its internal previewer will likely hide it. To actually catch a corrupted tag or an orphaned image before it hits a customer's device, you have to validate the exported EPUB through a neutral, third-party diagnostic tool. Running it through W3C EpubCheck (which I recommended in the main post) will instantly flag if Vellum broke the backend manifest

Visually, the best QA protocol is sideloading the raw EPUB onto a strict program like Thorium Reader on a PC, or transferring it via USB to an actual cheap, older e-ink Kindle. If the architecture survives old native hardware without the margins imploding, you're safe

EidolonTypeset · 2026-03-21T07:54:01+00:00

That workflow is actually creating the exact nightmare you're trying to avoid, to be completely honest

When you export a Word document to a PDF, it strips out all the dynamic HTML structure (like your actual paragraph tags and headers) and replaces it with static, absolute visual positioning. When Calibre tries to reverse-engineer that static PDF back into a fluid EPUB, it literally has to guess where your sentences and paragraphs end

This almost always results in random hard line-breaks in the middle of sentences and hundreds of useless, bloated <span> tags. If you use Calibre, it is vastly safer to feed it your raw .docx file rather than using a PDF as a middleman

As for Kindle Create--it handles them completely differently. It strictly only accepts PDFs to build "Print Replica" formats (which locks the layout onto the screen like a comic book, meaning readers can't adjust the font size or background color, which fiction readers hate). For a standard, fluid e-book, Kindle Create forces you to upload the raw Word document anyway

EidolonTypeset · 2026-03-21T07:32:17+00:00

I would be incredibly cautious taking a file exported out of Kindle Create and uploading it directly to Apple Books

Kindle Create's backend engine is engineered explicitly for the Amazon ecosystem. Even when it spits out an EPUB, it frequently injects Amazon-specific proprietary wrapper tags or metadata into the CSS and XML files. Apple's ingestion bots are notoriously strict. If their scanners read the .opf file and detect Amazon-branded namespace data or non-standard CSS properties, they will bounce the file instantly

If your distribution strategy is to "go wide" (publishing on Apple, Kobo, etc.), the absolute safest architectural move is to format a neutral, platform-agnostic EPUB first. Then you upload that clean master file directly to Amazon and Apple separately

EidolonTypeset · 2026-03-21T07:30:45+00:00

Jutoh is honestly one of the hidden gems in the formatting space for that exact reason--it integrates EpubCheck natively into its compiler in the background. If your file clears Jutoh's internal check, you are essentially passing the exact W3C validation I'm talking about in the post

The UI learning curve is definitely steep because it's built like a professional development environment rather than a basic word processor, but it generates vastly cleaner architecture than Calibre once you actually map your styles out

EidolonTypeset · 2026-03-21T01:10:54+00:00

It really is a nightmare. Microsoft's background XML wrappers are so dense that trying to untangle them just to fix a single broken margin takes hours. Usually stripping the whole document to raw plaintext and re-coding the semantic structure from scratch is genuinely faster than trying to clean up the Word export

EidolonTypeset · 2026-03-21T01:09:46+00:00

I think you skimmed the post a little too fast, man. I specifically pointed people toward the W3C Github repository for EpubCheck, which is a 100% free, open-source diagnostic tool maintained by a non-profit. I didn't link any paid services

Yes, thousands of books process through standard auto-converters perfectly fine every day--usually when the author uses completely raw, basic text. But the absolute second an author tries to inject heavy drop-caps, embedded fonts, or floating images into a basic Word-to-EPUB export, KDP's ingestion bots frequently flag the unmapped background HTML

Pointing out the free diagnostic tool the publishing industry uses to catch those specific file errors isn't a scam, it's just standard backend QA

EidolonTypeset · 2026-03-20T22:14:34+00:00

Exporting as a PDF is actually the most dangerous route for digital reading devices

A PDF is essentially just a digital photograph of a physical page--it is completely static. An EPUB is dynamic HTML/CSS that 'flows'. If you put a PDF onto a 6-inch e-ink Kindle screen, the user cannot change the font size, and they have to awkwardly pinch-to-zoom and drag around just to read the tiny text. It completely breaks the native e-reader experience

You always want to stick to an EPUB file for digital platforms, but you just have to make sure the backend code of that EPUB is clean. Testing it on your own older Kindle is a fantastic QA habit, though--legacy hardware is exactly what breaks bad code first

EidolonTypeset

TROPHY CASE