is now part of!

Undocumented Feature: Export to “Fixed-Layout HTML”


I was digging around in the InDesign CC 2015 “Object Model” today while working on a complicated script project, and I ran across this: Screen Shot 2015-07-29 at 3.50.19 PM

For those unfamiliar with scripting, this might not look like much. But it stopped me cold. This command didn’t exist in previous versions of InDesign. The documentation for the command simply says “Exports to XHTML FXL format.”

Wondering what “XHTML FXL format” is, I decided to try it with a simple script. Lo and behold, this command adds an undocumented export type to InDesign. When used in a script, it outputs the file as an HTML with proper supporting CSS and JavaScript to a “fixed layout” type of HTML format, that looks and behaves just like a fixed layout EPUB, with the big exception that each page is output as a single HTML file. Animation added via the Animation and Timing panels appears to be fully supported, as well as text and object hyperlinks.

Click here to download a script you can use to try this out for yourself.

The script asks you to choose a folder to save the HTML files into, and then names each file the same as the InDesign file with an html filename extension.


I thought I’d share this because I thought it was interesting, and it might be useful for someone in some way. I suspect this command is “under the hood” in InDesign due to the “technology preview” of the new Publish Online feature in the English versions of InDesign CC 2015.

While this is pretty amazing, it is no substitute for products like in5, since there is no way to automatically link the HTML pages together, no control over how the HTML is positioned and sized within the browser, and more.

Another caveat: at this point, it’s not clear how publishing documents this way fits (or doesn’t) with your font licenses. So it would be safest to limit your early explorations with this feature to documents using free or open source fonts.

Keith Gilbert is a design consultant, developer, educator, speaker, and author. His work has taken him throughout North America, Africa, Europe, and Asia. During his 35+ year career his clients have included Adobe, Apple, Target, Oracle, and the United Nations. He is the author of several popular titles for LinkedIn Learning, Adobe Press, and CreativePro. Find him at and on Twitter @gilbertconsult
  • What a marvelous discovery! I’ve been impressed with how Adobe is building bridges between InDesign, Photoshop, and Illustrator, along with iOS apps such as Adobe Comp. But I’ve been a bit disappointed that that bridges to HTML and Muse seem left out of that love-fest. I’d love to be able to easily export an InDesign book to a series of webpages introduced by a TOC and broken down by chapters.

    Maybe, just maybe, that’s in the works at Adobe. Thanks for the script.

  • Keith, you said “it outputs the file as an HTML with proper supporting CSS and JavaScript to a “fixed layout” type of HTML format, that looks and behaves just like a fixed layout EPUB, with the big exception that each page is output as a single HTML file.”

    … but that’s what InDesign normally does when it exports to a fixed layout EPUB. It exports each page as a single HTML5/CSS3 file. You can unzip the epub and everything inside the OEBPS folder is just what you’re describing: a series of named single-page HTML files with page elements absolutely positioned on them, and folders for fonts, scripts, and images.

    So the script is handy if you don’t want to unzip the epub manually, for sure.

    • Actually, the export appears to be subtly (but significantly) different than cracking an FXL EPUB, especially in how it handles fonts. Maybe different in other ways, too.

    • You’re right, Anne-Marie. This came about because I was doing just that. A client needed to extract hundreds of defined chunks of complex formatted text and illustrations from InDesign-created textbook pages. I wrote a script to batch extract to FXL EPUB, and then developed a post-processing workflow to crack open the EPUBs and extract the HTML and other needed files. Then I used BBEDIT’s way powerful “text factory” to do some batch modifications to the HTML and CSS files so that TypeKit web fonts were referenced instead of local OTF fonts. But, because of the way that the Export to FXL HTML works, none of this post-processing is necessary. The fonts are encoded in the JavaScript file.

      This is useful in this case because each chunk that we export is a single page, to be fed into a CMS for other purposes.

  • Peter says:

    They once had a technology preview of In5-type HTML5 export with full support for liquid layouts quite some time ago (it’s probably still on youtube or AdobeTV). That feature never saw the light of day as far as I am aware.

    In the next update, an item in the pages panel flyout menu showed up, I think under the Spread Attributes, which was related to HTML5 output, which never had any practical purpose and has subsequently been removed again recently if I recall correctly.

    My suspicion is that Adobe management purposely held back that feature because they wanted to sell that horrible but more profitable DPS nonsense with per-publication fees and horrible Flash panels, clumsy workflow and annoying non-native AIR-based utilities instead of letting everybody output to HTML5. Later they graciously gave us a bunch of “free” DPS publications included with CC to use that as an argument to get people to subscribe. Just like the “Publish Online” just looks like another scam to lock people into using Creative Cloud by not allowing them to self-host publications and thus making sure you and your client will definitely lose access to the final result, should you ever dare to cancel or pause your subscription.

    Let’s face it, how ridiculous is it that the most advanced desktop publishing software on the market still cannot properly export to HTML5 without third party add-ons? Instead we get mostly a load of CC bloat like CC libraries, Adobe Stock, Adobe Comp support and so on with only one or two important workflow fixes/features per update (table column/row reordering, footnotes, paragraph shading – all of which were already over-due several versions ago if we are honest). Not to mention we still need to install several more or less out of sync versions in parallel, developed by different external companies, or hackish plugins that unlock features with no UI to sort of properly work on international documents, and grayscale images are still not color managed in the year 2015 as far as I can tell.

    I love InDesign, it is probably my favorite Adobe software, but I hope that the release of Affinity Publisher early next year will put Adobe under just enough pressure to finally force management to let the developers do their homework and innovate again instead of just enjoying the market dominance.

    • Inkling says:

      You’ve touched on one of my complaints about the current status quo. Adobe’s creating some marvelous tools for displaying content, including Publish Online and Adobe Voice. But like many, I get a nagging suspicion that I don’t control and thus don’t own content that has to be hosted by Adobe.

      That makes no sense. Adobe products should be about content creation not content hosting. We have full control of what I do with the PDFs that InDesign creates. We need similar control of Publish Online and Adobe Voice content.


      As for this remark: “Instead we get mostly a load of CC bloat like CC libraries, Adobe Stock, Adobe Comp support and so on with only one or two important workflow fixes/features per update…”

      I know exactly how you feel. But you’ve got to enter the minds of corporate executives who think in terms of corporate organizational charts. What you see as “CC bloat” they see as corporate growth. Adobe Stock adds a new block to the org chart, new sources of profit, and new positions for executives like themselves. That makes it good in their eyes. They don’t use InDesign, so the scarcity of “workflow fixes/features per update” never enters their mind.

      Recently, I’ve begun to realize that a lot of what seems to be malice or stupidity is really the result of a narrowness of vision. Adobe’s executives simply don’t understand what ID users want and haven’t learned to listen to those at Adobe who do. They only see their own experiences conditioned by their own wants and needs, hence that “CC bloat.”

      For an illustration of someone who has grown enormously rich adopting a different POV as a CEO, you might study Rupert Murdoch, the billionaire media mogul. Much of his success rests on seriously asking about and supplying what the readers and viewers of his various publications and media outlets want. He may have started with turning an Australian newspaper into a sensationalist tabloid, but he has no interest in doing the same with the Wall Street Journal. Each has a different audience to be satisfied.

      All too many corporate executives fail to realize that. They see the world through their eyes and their eyes alone.

  • Eugene Tyson says:

    This is amazing!!!

  • Anita says:

    I really enjoy using Publish Online. However, how long will we be allowed to use it before Adobe pulls the rug from beneath our feet again? Unfortunately, the money men have too much say!

    I, too, am looking forward to Affinity Publisher being launched, as Adobe needs a proverbial kick up the backside. They obviously have forgotten what happened to Quark!!

  • Royston Marshall says:

    Hi Keith

    I saw you give the last day talk in Washington last week, and was very impressed with this discovery!
    I will be needing something like this very soon, and this will certainly be a springboard for me.
    I am a scripter, and will using this preference in my requirement, but was a bit concerned that searching the ESTK Object model did not find any reference to this either! I only found it in the excellent documentation Jongware has put together.

    Thanks again for the insight!

  • Mario says:

    How to install the script?

    • Monika says:

      Hey, when I try to install your code to my InDesign it doesn’t work.
      InDesign doesn’t understant that it is script.

  • Andy says:

    Hi Keith, great plugin.

    A couple of minor changes for your next release:
    • The first page needs to be numbered -0 or -1 when output, it is currently ignored.
    • Files names could do with some zeros for ordering when you have over 10 pages, so that 1 can be kept apart from 10, 11, 12. (i.e. 001, 002, 003, …, 010, 011).
    • It would be handy if the plugin spat out some PNG or JPEG renders to sit alongside the HTML pages as previews.

    Keep up the skills!


  • Surjith Sankaranarayanan says:

    Hi Keith,

    The plugin is not working in InDesign CC 2019. Is the script is compatible with this version? Please help.

  • Wayne says:

    The script works fantastically in the latest version of InDesign.
    The only thing I don’t quite understand is how to change the output size.
    My Indesign document measures 737 pixels wide. However after running the FXL script, the HTML document and background image size exports to 1535 pixels wide. Can I change the export size?

    • Keith Gilbert says:

      @Wayne, in my tests, the output size is exactly the same as the InDesign page size. The script outputs a fixed-width DIV for each page the same dimensions (width and height) as the InDesign page.

  • >