See you at the Electronic Document Conference?

The PDF Association’s Electronic Document Conference in Seattle in June this year is a do-not-miss event for technical product managers and developers working with PDF documents.

We’re proud to be presenting an educational session there on using serverless technologies (eg AWS Lambda) for highly parallel Word to PDF conversion.

A use-case where serverless shines is eStatement production in the banking, telecom and utilities sectors, which with a PDF per consumer, often involves millions of PDFs once a month, generated by merging customer data into a Word template.

With serverless technologies, you can scale up to handle this workload, without paying for idle capacity through the remainder of the month.

PDF Conversion workloads on the client

Last month we published our docx-wasm NPM module, allowing you to perform Word document operations wherever you can run NPM.  For example, to convert Word documents to PDF.

With the sample code in our readme, it is trivial to do this server-side.   It is also easily adapted to serverless, for example AWS Lambda (with or without an AWS Step Function).  We’ll be speaking about this at the PDF Association electronic document conference in Seattle in June, but in the meantime please see our docx-to-pdf-on-AWS-Lambda GitHub project.

How about client-side?  As soon as we published the NPM module, we were asked “can you run it in a web browser?” 🙂

The answer is “Yes!”, and it works nicely.   The browser needs to get the code from somewhere, of course.  You can get it at  Or you can serve the code yourself, using

Why is this interesting?  If you are running a popular SAAS business, server costs can mount up quickly.  Especially with conversion workloads, which are CPU intensive.  So shifting the workload to the client can reduce costs.  By cutting down on network traffic, it can also improve responsiveness.  Then there is the possibility of running offline – PDF conversion in node, without a network connection.

If this is something you’ve been waiting for, please get in touch!


docx-wasm: working with Word documents in node

Native Documents is pleased to announce the first release of docx-wasm, our general purpose library for working with Word documents in nodejs.

If you think about Java or .NET, developers in those environments have long had decent libraries with which to manipulate Office documents. In Java, there is docx4j and Apache POI. For .NET, Microsoft itself offers its Open XML SDK. In addition to these open source offerings, there are commercial products such as Aspose.

These libraries variously provide low level and higher-level APIs for manipulating Open XML files. For example with the Java libraries and Aspose, there are higher-level APIs to extract text, insert a paragraph, convert to PDF etc. With docx4j, POI and the Open XML SDK, you can also manipulate the XML directly, which means that in principle you can do anything the file formats allow (which includes creating documents Office can’t open!)

Javascript is the most popular programming language on GitHub and StackOverflow, and yet there are no libraries of comparable breadth and depth.

Yes, there are some simple libraries for creating documents, but if you wanted to do something more complex, you’d be disappointed.

Take docx to PDF conversion for example. On NPM, you can find projects which try to solve this by first converting to HTML (ie with loss of fidelity), by relying on some remote API, or by using LibreOffice or unoconv.

To go direct from Word to PDF, you need a library capable of Word document layout. And up until now, that’s been missing.

Here at Native Documents, we’ve now delivered this missing piece, opening the way for things like PDF conversion without nasty “hacks”.

The secret to our approach is given away by the name we chose for our library.

We’ve taken the Word-compatible layout engine we developed for Word document viewing, editing and PDF conversion, and compiled that to WebAssembly (the newish binary format for executing code in node and on the web).

A single code base is used across environments and use-cases, which means a layout fix for our viewer, say, is likely to bring the same improvement to our PDF output.

In docx-wasm, this code is executed where you choose to run node. This means that document manipulation is done locally where you are running Node, so your sensitive documents remain under your control, and aren’t entrusted to some random service halfway across the planet.

This release focuses on converting Word documents to PDF.  Since our code can handle both docx files and the older binary .doc format, we’ve also included binary .doc to docx conversion.

To give it a try against your documents, fire up our sample code in Node.

Just integrate Word Online?

As everyone knows, nowadays there is Word Online.

So why not just use that in your webapp? Specifically:

  • on-premises: Office Online Server (previously Office Web Apps)
  • on the web: as a Microsoft Office Online Cloud Partner

This is actually harder to achieve than it sounds, and if you do do it, it may turn out to be something of a mixed result:

  1. each user must have an Office license
  2. it’ll still come up in a separate browser tab or window
  3. WOPI integration is not so easy
  4. you’ll need Windows Servers
  5. its Microsoft you’d be dealing with
  6. and Word Online is still different to Word

Let me step through these one by one.

But before I do that, let me emphasise that we don’t see things as “Native Documents vs Microsoft”.  The beauty of the docx standard is that you can use docx files in Native Documents and whichever of Microsoft’s Word apps you need to.

Microsoft’s licensing strategy

Business users require an Office 365 subscription to edit files in Office Online. When business users open documents for editing, Office Online will validate that they have a valid Office 365 subscription. This may require the user to sign in using a valid Office 365 business account.

For in-house use (Office Online Server), in order to be able to edit documents, a user must have a suitable Office license: typically an on-premises Office license with Software Assurance or an Office 365 ProPlus (E3) subscription.

So, unless all your users have suitable Office licenses, integrating with Word Online will leave some of them out in the cold.  Clearly, this is a major problem for any application accessed by customers and other external users.

Word Online use case

Word Online is designed primarily as a standalone product – for use when Word proper is not installed – rather than as a component or service developers can integrate into their applications.

This means that in tradeoffs at Microsoft between a consistent end user experience and developer needs, developer needs come second.   So we see very limited ability to change the user interface or interact with it programmatically.

For example, Word Online wants its own browser tab/window; you can’t put it in an iframe within your app.

WOPI = World Of PaIn!

To integrate with Word Online, you have to use Microsoft’s Web Application Open Platform Interface (WOPI) protocol to implement a WOPI host, and jump through some other hoops (as detailed in that link).

Let’s just say WOPI is not designed to be easy to integrate.

In comparison, here at Native Documents we’ve worked hard to make things as simple as possible for you.  The result is that to use Native Documents,  you just need to implement 2 callbacks:

  • one to provide a document to be edited,
  • another to handle an edited document when the user is done editing

That’s it.

Windows Server

Word Online runs on Windows Server, not Linux, increasing your costs in the cloud.

In contrast, our Word File Editor runs in a Docker container, which you can easily deploy in a docker environment.

Its Microsoft

If you did decide to integrate Word Online, it’s Microsoft you’d be dealing with.

On the one hand, a large corporation you know well, and of course the creator of Office itself.

But on the other hand:

  • little chance of customisation/enhancement to meet your specific needs
  • you do business on their terms

And size is no guarantee that things will work properly, or be fixed quickly.  For example, the DropBox integration with Word Online was recently broken for iPad users for some 14 weeks, from 4 Feb to 16 May 2018.

But Word Online ain’t Word

There are differences in how some documents look in Word Online as compared to Word.  The top issue at for Word Online by a wide margin is “Word Online should have all the features of normal word”.

And “long” documents might be a problem.

Word Online is best thought of as mere one of a number of editors which can be used to edit docx files.  Native Documents is another.  That’s the beauty of an open file format.

But for all these editors, the gold standard for interoperability is Word (2007, 2010, 2013 or 2016) on the Windows  desktop.

We can only suggest that you test your documents in Word Online.

And of course, invite you to try them in Native Documents: you can simply drag/drop your own Word (docx or binary .doc) file.

In Summary

With that we’d like to invite you to give Native Documents a try.  You’ll be pleasantly surprised how easy it is to get started, and delighted, we hope, in our responsiveness to your needs.

Is Word available on this device?

Back in the day, say, oh, 2003, every corporate desktop had Word installed, and that desktop was a Windows PC.

Documents were stored in a file share, or Documentum (pharmaceuticals) or iManage or Hummingbird (law firms).

These tools relied on Word being installed to do the editing, with help from protocols such as WebDAV and SharePoint.

Fast forward to today, and you might be using a Mac.  Or a mobile device.  And there’s a good chance you’ll be using a browser based interface.

Is Word installed on the device you are using right now?  What about your other devices?

As an app developer, can you still get away with expecting the user to save/download the file, edit it whatever tool might be at hand, then upload it again?

  • At best, this involves extra clicks (compared to editing what you see in the webapp).
  • If the user doesn’t just think “too hard”, then they might “break the document” by using their installed application (eg Pages on iOS).
  • Unless you have the luxury of a standard operating environment (SOE) which covers mobile, then your help desk is going to get calls around a combinatorial explosion of different applications and platforms and versions.  Not to mention locales and fonts…

A much better experience is to be able to edit the document right there in your webapp.  Easier and more intuitive for users.  Lower support costs.  And the possibility of giving the user a tailored experience which isn’t feasible if the wordprocessing component is outside your control.

I guess this is a no-brainer.  We’re currently seeing the “bar being raised”, where web apps are now expected to provide not only viewing, but in-app editing.

Leading the charge here are the so-called file sync n share apps like Dropbox and Box which integrate with Office Online, even as they compete with Microsoft’s OneDrive product.

My next post will show you why Native Documents could be a better option for your webapp!

Converting between DOCX and HTML considered harmful

So, you are building a web-based application, and the requirements include that users can view or edit documents.

Let’s assume these are Word documents.  Treating the Word document as the canonical or “single source” or “one version of the truth” makes sense, because this is what users expect, and will complain about if what they see looks different to what they’d see in Word.

So how do you ensure that what they see looks the same as what they’d see in Word?  And if you can meet this requirement, how does editing work?

Its fair to say that the position has typically been: fidelity or editing, pick one.

If you start with tackling the editing problem, you might think, convert docx to HTML, edit with CKEditor or TinyMCE, then convert the output back to docx.  Job done!

The problem with that though is a never ending stream of annoying fidelity problems, especially around numbering.  Either it doesn’t look right in the web editor, or it looks OK there, but wrong back in Word.

A golden rule is to avoid conversion between document formats wherever possible!

Don’t get me wrong, CKEditor and TinyMCE are both great products, terrific for editing HTML across Chrome, Firefox, Safari and Microsoft’s.  This blog uses WordPress, so I’m actually writing this post in TinyMCE. Its just that they were never designed for editing Word documents, and so its no surprise that that use case doesn’t work so well.  Word and the web do not play nice together.

Or you might start with a PDF, knowing you can convert docx to PDF and retain the visual fidelity.  Then there’s Mozilla’s pdf.js  (or maybe Google’s PDFium)  for viewing it in the browser.

But you can’t edit it!  Well, some PDF tools enable you to do a little bit, but good luck inserting a new sentence or paragraph.

So HTML and PDF are dead ends.

What other options are there?  The following spring to mind:

  • rely on Word being installed
  • Word Online
  • Google Docs

But your best option is Native Documents, which allows you as a developer to work directly with the docx in a web browser, so you never need to worry about docx to HTML, or converting XHTML to docx. Our editor never converts to HTML: it uses Office Open XML natively, and renders using React.

To show why this is your best option for a “native” docx architecture, our next posts will explore the Word desktop and Word Online options.

Google Docs we’ll put to one side.  Its not designed to be integrated into a webapp, it involves sending potentially sensitive information to Google, and it still has a bunch of issues with Word documents which will never be solved (10 years+ so far…).




The docx file format after 10 years

If you are designing or architecting a mission-critical, document-intensive system, then a key question is “what document format should I use?”

If you need to edit the documents, then PDF is out.

Docx is the obvious choice, and after 10 years in the market, its interesting to review the events which have led to its dominance.

Microsoft Office itself has reigned for 20 years.  Or is it 30 years?

There is room for debate about when its reign started.  Word for Windows was introduced in 1989, and it steadily gained marketshare until by 1997, it had 90% of the US market.

It has seen off various threats along the way, and it is Microsoft’s response to these that have shaped the Office we know today.

The four threats are (or rather, were):

  • the web (take 1)
  • OpenOffice
  • Google Docs
  • the iPhone-led and web-based (take 2) shift away from Wintel PCs

Microsoft’s response to these threats has been so effective that:

  • Office is how Fortune 1000 knowledge workers have edited documents and spreadsheets for 20 years, and although this may be changing slowly, change is very slow
  • if you open a Word document in anything else, it should “look like it does in Word”
  • Office has become a platform, with all the usual characteristics of an  ecosystem.  Or rather, the Office file formats have become a platform.
  • All sorts of systems generate documents from templates: from contracts to reports to invoices to HR documents. So much so that more Word documents are probably created by programs than by people.

After reading the rest of this post, you’ll see why we here at Native Documents have “bet the farm” on a high-fidelity Word compatible editor designed for modern HTML 5 browsers.

The Web (Take 1)

In the late 90’s, Microsoft (specifically, Bill Gates) was worried that HTML as a document format might take over from Office.

I don’t want to focus on this too much here, but I mention it for completeness.

Suffice to say that we now live in a world where HTML5 is ubiquitous, and used as the basis of an every increasing range of new webapps.  It is no exaggeration to say that HTML is the key to all of the apps we enjoy today, in our web browsers, and often on our mobile devices and even desktops.

That said, the Office document formats have remained firmly entrenched in the areas they were designed for:

  • complex business documents, that are often shared and modified by multiple authors, often across organizational boundaries
  • in business processes, pulling in data from corporate systems (eg SAP and Oracle databases)


Let me start by saying OpenOffice is important to this story for personal reasons.  Two of our founders (Gary and Jason) met at the first Open Office XML Format technical committee meeting in Dec 2002.  And Florian was the engineer at Sun and Novell responsible for interop with Word.

OpenOffice is important because it forced Microsoft to open its formats, and move to XML.  It is thanks to OpenOffice that the docx file format is an ISO standard, and open to anyone with unzip and XML editing technology.

It is also important because it re-inforced to Florian that visual fidelity is important, and must be baked in from the start.  It was this that led eventually to us starting Native Documents, Inc. to solve the problem of WYSIWYG for Word documents in web browsers.

Suffice to say that with the introduction of docx in Word 2007, Microsoft saw off the OpenOffice threat, and changed everything.  With the opening up of the docx file format, the momentum behind all attempts to establish a real alternative quite simply disappeared.

The transition to docx was a great success, and by re-energizing the Office eco-system with a new-found openness, the dominance of Office and its file formats has become even stronger.

Google Docs

At the same time, another threat came from out of nowhere.  Google Docs.

The history is well known.  Back in 2005, Sam Schillace developed a new webapp called Writely, exploiting then-new Ajax technology and the “content editable” function in browsers.  Google bought the company Upstartle, and soon, Google Docs was born.

Google Docs introduced collaborative, or real-time co-editing, and allowed anyone with a web browser to edit.  No need to have Windows or install anything.  And it was free.

It made Microsoft sit up and take notice, and led eventually to Word Online.

Google Docs has never been able to crack into Microsoft’s dominance in enterprise accounts, and with Microsoft’s pivot to the cloud under Nadella (especially hosted Exchange), its hopes of doing so have long since faded.

Still, the Google Docs story underscores how advances in web technology make new things possible. A decade later, it is advances like HTML5, React, and Web Assembly, which have made our Word file editor possible. More on this in later posts.

So long, Wintel..

Its not that nobody uses Windows PCs anymore, but rather, that they also use Apple (iPhones, iPads, desktops) or Android or Chrome or whatever else might be handy and running a web browser.  Linux?  I’m writing this post using KDE Neon.

And wisely, Microsoft has freed Office to run on these other platforms.  It has always worked (mostly) on Mac OSX, but these days it also runs natively on iOS and Android.  And for platforms which aren’t specifically supported (eg Linux), you can use Word Online.

By embracing a “Word everywhere” strategy, Microsoft has done what is necessary to help ensure the long term dominance of Office as a platform.

Where does this leave us?

It leaves us in a world where Microsoft’s Office file formats are dominant, stronger than ever, and therefore a given, wherever people across organizations need to work on a “serious” business document.

It leaves us in a world where developers continue to build enterprise systems which manipulate documents in the Office Open XML formats.  It is easy and safe to do so.  And practical alternatives (eg XML based single source publishing)  remain niche solutions.

It leaves us in a world where docx, HTML and PDF are the three main document formats, none of which are going away. But only one of which is suitable for editable business documents.

However, working with Word documents in a browser is not so easy, particularly if you want to seamlessly integrate this into your application.  So your users can view/review or modify a document.  Our next post explores this critical challenge.