Maximum file size for HTML files within EPUB?

[Psymon]

I seem to recall having read in some thread somewhere in the past -- but couldn't seem to find it again -- that there's a maximum file size for the individual HTML files within an ebook? I think it was something like 264kb or something around there.

Is that for real? In this Shakespeare book I'm working on, I have some files -- entire plays of his -- that are over 300kb (and one around 450kb) and in ADE on my PC, and in iBooks on my old iPad2, I don't seem to have any issues at all with them.

I should probably mention (as I have elsewhere, in other threads) that I had only intended to put this book up on the iTunes store -- pleeeeeeze don't shoot me! -- but at the same time it would be nice if it worked all-around, of course, in case I do want to give it to someone for use on another device. I'm just not sure in what context file size would be an issue -- if, in fact, it is indeed an issue.

[JSWolf]

I believe it's 300kb for mobile RMSDK (ADE). I know Sony Readers adhere to that and will show an error if you exceed the limit.

[pdurrant]

Old versions of the Adobe ePub rendering software had a 300KB limit, but that was eliminated in 2009.

See this post at idpf

Only really old ebook readers (e.g. Sony PRS-500) will have any problems with more than 300KB per file.

[Psymon]

Hmm... okay, thanks, guys. I guess I should probably split the files -- I suppose it wouldn't do much harm to do so, splitting each play at every act or something. I would prefer not to, but nothing's perfect in ebook-land.

Thanks again!

[Toxaris]

Originally Posted by pdurrant

Old versions of the Adobe ePub rendering software had a 300KB limit, but that was eliminated in 2009.

See this post at idpf

Only really old ebook readers (e.g. Sony PRS-500) will have any problems with more than 300KB per file.

Actually, the PRS-300 and the PRS-x50 series suffered the same. My PRS-T1 does open bigger files, but will get slower near the end of the file. At one time turning a page took almost two seconds. That file was around 600 KB I believe. So, it is mainly for older devices, but newer devices (not that I consider the PRS-T1 'newer') can become slower. This is probably especially true for e-ink devices which are usually not that generous memory and CPU wise.

[JSWolf]

I would stick to the 300KB limit regardless. It's good practice plus it means if you do to to sell this in other places, people with older Readers such as Sony can read it no problem.

[Psymon]

Originally Posted by JSWolf

I would stick to the 300KB limit regardless. It's good practice plus it means if you do to to sell this in other places, people with older Readers such as Sony can read it no problem.

Yeah, I pretty much made that decision earlier. I already split up all the plays at each act, and it hasn't really affected things dramatically -- pun intended, ha ha.

[eschwartz]

If you use a separate HTML file per "chapter" (or depending on the type of book, whatever it is that gets a pagebreak), you will rarely if ever go over the limit even on old devices.

So it should never actually be a problem if the ebook producer follows good design practices.

[theducks]

Calibre defaulted to 260K
I recommend this (or smaller) if your book sections have many or large illustrations for those that keep on using that which still works

Beside, performance is usually better with less to render

[GeoffR]

Current versions of Adobe RMSDK can handle larger files, but they appear to do it by splitting the file internally into smaller chunks, which results in an extra page break between chunks. I've seen this happen with files of about 150KB - 200KB in size, but it might depend on how much memory is available on the reading device.

It is much better for the publisher to split the files, that way the publisher has control of where the extra page breaks occur.

[fbrzvnrnd]

Some recent ereaders like Onyx M96 are still slow with ePub with large xhtml file inside.

[dgatwood]

Remember that the time to open the book is proportional to the time required to reflow the current chapter. The slower the CPU and the more complex your styles, the longer this will take. I would shoot for on the order of thirty or forty screens of content per chapter, so tens of kilobytes rather than hundreds. That'a not a hard and fast rule, though. I definitely wouldn't go as high as half a meg worth of text, though. :-)

[Notjohn]

I definitely wouldn't go as high as half a meg worth of text, though.

That would cover all my novels, I think. (Since I use Sigil for formatting, it's actually easier to split the file into 30 or 40 or 50 smaller files, so as to automate the updating of the TOC.) I assume that images would also be included in your rule of thumb? My illustrated books run around 2-2.5 MB.

Thanks for clarifying this business of multiple files, which I didn't encounter until I began using Sigil and uploading books as epubs.

[Turtle91]

Images shouldn't, by themselves, cause any issues with file-size limits. At least, not as far as I'm aware?? But... those older systems might have separate image size limits.

There have been a few threads here that discuss how to minimize image size while keeping acceptable quality - even for hi-res images. For example, I see images of the title page that are 250KB...I either convert them to straight text and trash the image, or, if there is some special graphics on the image I can usually reduce it to about 50KB or less without discernible loss.

Most of my epubs finish up in the sub 1MB range....unless there are specific chapter head images or somesuch...those can jump up to 1.5MB. Other than my CDO (OCD in proper alphabetical order) drive to minimize space, the total size doesn't really matter as much as the size of the individual files - which I wouldn't expect a problem if you break up the chapters into individual files.

Cheers,