EPUB Compile Errors

A Merry Xmas to one and all.

Currently pulling my hair out as I have just uploaded my new book (via ePub compiled in Scrivener 3.2.3 for Mac) on Smashwords and have received an error report stating 123 instances of “ERROR(RSC-005): OPS/body.xhtml(6, 71): Error while parsing file: A document must not contain both a meta element in encoding declaration state (http-equiv=‘content-type’) and a meta element with the charset attribute present.”
I have since searched like crazy online but am still none the wiser. It seems like the error repeats in the html body section of every individual scene (i.e. body.xhtml, body1.xhtml, body10.xhtml etc.).
If anyone can shed any light on this issue, not only would they make my day, I would happily revere them for the foreseeable future. It uploaded to Amazon without error and the resultant Kindle version looked exactly as I expected it. All ideas/thoughts are welcome.

Thank you,

Maybe this is why Literature & Latte doesn’t recommend using styles for ordinary paragraphs. You’re using ten body styles, though? Either way, if it looks good and Amazon likes it, Smashwords should also.

1 Like

I found Smashwords ePub verifier picks every issue and rejects regardless of whether the same file impacts presentation on Amazon.

1 Like

I’m not sure how the html side functions to be honest. I edited every scene outside scrivener (in Word) and the copied and pasted back over a copy of the original scrivener scenes one at a time ensuring that I ‘matched style’ each time. No individual settings were ever made and I figured all settings would be global. I’ll get back on with the investigation today. Seems like support is away until 3rd Jan so looks like some intensive Googling is on the cards unless I get lucky on the forum. Thanks for your thoughts.

Yes, I’m sure you’re right. I think they still sell the book on their own site and the extra requirements are to allow the submitted work to be distributed to the 3rd party outlets like Banes & Noble etc. Thanks for your thoughts.

Copying and pasting from Word can have unintended effects.


Are you using the old ePub 2 generator or something? I can’t reproduce this type of error using the modern ePub 3 setting. There probably isn’t any reason to be using ePub 2 unless the provider specifically does not support ePub 3.

The problem is specifically one of how the internal HTML files are declared in the header, it has nothing to do with formatting, or whether you copy and paste from Word, etc. Here is what an HTML header looks like in the modern ePub3 output looks like:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops">
	<meta charset="utf-8"/>
	<title>First Chapter</title>
	<link type="text/css" rel="stylesheet" href="css/stylesheet.css"/>

And here is the older header:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <meta http-equiv="Content-Style-Type" content="text/css" />
  <title>First Chapter</title>
  <meta name="Generator" content="Cocoa HTML Writer" />
  <meta name="CocoaVersion" content="2022.6" />
  <link rel="stylesheet" href="css/stylesheet1.css" type="text/css" />

So as you can see, in ePub3, there actually are no “http-equiv” meta settings, as there are in the older specification.

Thus it could be Smashword’s verification system isn’t capable of detecting that you’re using ePub2 specification, and is trying to test it as ePub3 and rightly failing. As I say, it’s probably just best to use ePub3 at this point and it would probably avoid the problem you’re seeing anyway.

@drmajorbob: Maybe this is why Literature & Latte doesn’t recommend using styles for ordinary paragraphs. You’re using ten body styles, though? Either way, if it looks good and Amazon likes it, Smashwords should also.

You’re referring to the naming scheme for internal HTML files in the epub. “body.xhtml” would be the first main section, “body1.xhtml” the second and so on. That has nothing to do with styles.

1 Like

Thanks for your thoughts. I don’t have the option to choose between epub 2 or 3. I’m pretty sure that it’s a 3 as it’s quite a recent version of Scrivener and I think we lost the choice once they’d wrapped up all the bugs.

Yeah, ePub 2 was deprecated some time ago. It’s still in the software, but it only shows up if you have compile formats that request it (so older projects wouldn’t break). If you don’t see it in the Compile for dropdown, then it should be ePub 3.

And in that case I have no idea how you are getting “http-equiv” output. If you open the compiled .epub file in an ebook editor like Sigil, do you see something more like the first or second example above? If what you are uploading looks like the former, then I can only speculate Smashwords is making a mess of things on upload and trying to process the HTML.

1 Like

I know Amber, it’s all a bit weird. I ended up unzipping the epub and deleting the old code from 123 html files, rezipped and revalidated and then sent. Seems to have done the trick but wouldn’t want to repeat the process if I need to make a change and reupload! Thanks very much for your input.

Well that does at least mean that it is potentially something we can fix, or perhaps decipher how your settings got to making things work that way. If you get a chance to, send us a sample of the project to our tech support address, with this thread URL mentioned.

“Sample” in this case really only means the minimum amount of content it takes to demonstrate the problem. For example you can use Save As to create a copy that you strip down to one chapter, and get the same result, that’s even better for us than an entire project. But feel free to just zip it all up and send it if that’s easier for you and you’re comfortable with that.

Hi Amber, have tried several ways to show/upload/screenshot offending xhtml code on here but nothing works. Perhaps I’ll have another go when I have more time. I have a ticket in so maybe someone will have a look after the hols. Thanks so much for your help.

No worries, to reiterate the above it’s really what generates the XHTML that matters to figuring out the problem. We can know what you get, but have no clue how it got to be that way, which is why some portion of the project that generates the code that way is what we need.

I’ll pick it up after New Years! Thanks for helping us track it down.

I’ll get it to you in the New Year.

As an update, another individual ran into this problem and contacted tech support, and it was noticed that they were using the Optimize for Kindle conversion checkbox, in the general options tab of the compile overview screen.

This setting should only be used when needed and if it works, essentially, as it produces a deliberately sub-standard ePub file. Thing is, for some aggregators, that’s actually better than a good quality ePub.

It also shouldn’t be used for Amazon KDP and Kindle Previewer itself, which reads normal ePub files just fine.


Hi Amber, yes I did have that very box ticked. I will try without and check the code in the resultant xhtml files. Sounds very likely that you have resolved my issue and I will keep you posted. Many thanks for your help.

Just ran EPUB-Checker on a new compile without Optimize for Kindle conversion checked and it passed with flying colours. Thanks Amber, you’ve made my life a whole lot easier.

1 Like

I’m using Scrivener 3.2.3 on macOS – latest update. I’m compiling my manuscript to EPub and trying to upload it on Draft2Digital, which validates the file and reports errors (the same one on every chapter)

ERROR(RSC-005): .tmp.tmpx_c9odva.epub/OPS.body.xhtml(6,71): Error while parsing file: A document must not contain both a meta element in encoding declaration state (http-equiv=‘content-type’) and a meta element with the charset attribute present.

Opening the file with calibre, I see they contain:

<meta charset=utf-8/>
<meta http-equiv=Content-Type content=text/html; charset=utf-8 />

Which I guess is what the error is about, though I don’t understand it.

Does anyone know if this is:
(a) a bug in Scrivener
(b) a bug in the epub validator
(c) something I can fix myself (and if so, how?)


You can remove one of those lines using Sigil or Calibre, I think.

Well – I could, but there’s a hundred or so files, and I’ll have the same problem every time this or any other book is compiled. So I’d rather the EPub was generated correctly in the first place.