Making sense of the Adobe XD file format

How to avoid error 86 on Adobe XD files modified "externally"

TL;DR

There are many reports over the internet of people trying to open Adobe XD files and getting “error 86”. As far as I can tell, this is the first place you can read this information: to avoid “error 86” when opening the file in Adobe XD (or at least one possible cause of the error) , the “mimetype” file must be the first entry in the ZIP container, and it must not be compressed.

Come again?

I realize that the above might not make much sense unless you are already familiar with the XD file format, so let me explain in a bit more detail. An Adobe XD file is a ZIP container, or a file that you can rename to the .zip file extension, and unpack like any ZIP file. Inside the ZIP, you will find many other files, including image files in PNG format, or JSON files describing the layout, the design elements, as well as the text content. Making a file format a ZIP container is common practice for software makers: among others, Microsoft uses it for Word, Excel, and PowerPoint, and the EPUB ebook file format is also a ZIP container, as well as many others. Since an Adobe XD file is a ZIP container, you may expect to be able to make changes to it without opening it in the dedicated application. Theoretically, nothing should stop you from modifying your XD file following these steps:

1. change the extension to .zip,

2. extract the contents,

3. make any changes you need on the level of individual files,

4. pack everything back to a new ZIP file,

5. change the extension back to .xd,

6. and open the file again in Adobe XD to confirm everything worked.

So does this approach work for Adobe XD? No: if you perform these steps, Adobe XD will tell you that the file is not a valid XD file, and presents an error number of 86, as if that made any sense to you, or made it possible for you to troubleshoot the problem.

What causes error 86 here?

I first encountered this error a few years ago, trying to support a customer who had this issue trying to translate Adobe XD files. Translation is a basic use case for modifying an XD file “outside” Adobe XD: to translate an XD file with any efficiency, you would want to process it in a professional translation tool, not Adobe XD itself. So you (or your translation tool) would want to extract the contents of the XD file, identify the words to translate in the JSON files inside, modify the JSON files by translating the words, and pack the file back again using a ZIP packer. (Actually, using a modern translation tool like memoQ, you can automate most of these steps.)

At my first attempt to get to the bottom of this, back in 2020, I didn’t fully understand the problem yet. But I suspected it was something about how the XD file was packed back up: even if I didn’t change anything about the contents of the file, but just unpacked it and packed it back up, the file got “corrupted”. People normally don’t think much about how a ZIP file is structured. When creating ZIP files, depending on the tool you used, you may have noticed an option for the “compression level”, ranging from simple “storing” (with no compression) to maximum compression. This is a tradeoff between time spent packing and unpacking versus the file size: the more you compress the file, the smaller it can potentially get, but it will also require more time to pack and unpack it (on the same computer under identical circumstances). Digging further, you may learn that ZIP files also consist of “entries”, each entry being a file or folder stored inside the ZIP. Entries are also sequential, meaning they are stored one after the other in the ZIP, and an ordinal number is assigned to each of them.

So, what causes error 86 in the “unzip, modify, zip again” scenario? It’s simple: there is a “mimetype” file in the root folder of the zip, and this file must be the first entry (entry #1) in the ZIP, and it also must not be compressed. If these conditions are not met, Adobe XD will give you error 86 instead of opening the file. I mean, it is simple for me to write the solution down after having banged my head to the wall for many hours until I finally figured it out.

For all my testing, I used the latest version of Adobe XD that was available to me at the time of writing. It is possible that earlier versions of Adobe XD had a somewhat different logic for file opening, and those earlier versions might have been pickier. The latest version is picky about this single thing only: the mimetype file must be the first entry, and it must not be compressed. The way the rest of the ZIP is compressed doesn’t matter: the other files can be included in any order, and can be compressed to any level, as far as I can tell.

A workaround without full understanding

When I first saw this problem back in 2020, even though I didn’t yet know the exact root cause, and only suspected that problem was related to zipping, I could still come up with a viable workaround. I figured that if the error was caused by some unknown detail in the ZIP file’s innards, a workaround approach could be to make sure that we apply our changes to the XD file by modifying the ZIP file structure as little as possible. The translation of an XD file involves the changing text elements in some of the JSON files inside the XD / ZIP container file.

So, when finished, the workaround to prevent error 86 on opening was not to create a brand new ZIP file by packing everything up, but to go back to the original XD file and overwrite just the individual JSON files that got translated. In your favourite ZIP packer, just open the XD file as a ZIP, and overwrite the files you need with their new, translated versions. This worked, but at the time, I didn’t yet know why it worked: it didn’t change the order of the files inside the ZIP, and didn’t change how the crucial “mimetype” file was stored in it, so it didn’t cause error 86 when opening the file in Adobe XD.

How I found the exact root cause

There are many software tools which go beyond just zipping and unzipping ZIP files, or browsing their contents. In the excellent 7-Zip, for example, you can also see the compression level individually for each file, and can see where each stored or compressed file is located inside the ZIP. For a long time, I didn’t pay any attention to the order of files inside the ZIP. The compression level was more suspicious, and I also had other suspects, like the algorithm used to compress the files. Or perhaps something else I wasn’t even aware of. I was researching and found that some command-line ZIP tools can create a text report describing the ZIP file and each individual entry inside. So, I created a minimal document in Adobe XD, and saved it to a “good.xd” file. Then I unzipped the file and zipped it back again to create a “bad.xd” file that would no longer open and would give me an error 86. And I ran it through GNU’s unzip.exe with the -Zv switches, and sending the output to a text file like this:
unzip.exe -Zv "c:\path\bad.xd" > bad.txt
unzip.exe -Zv "c:\path\good.xd" > good.txt

After this, I had two text files describing the contents of the “good” and “bad” zips, having something like this in them:

The two TXT “report” files had the stored files inside in a completely different order. I didn’t yet realize it as a potential problem, but I started editing the bad.txt file to change the order of the entry descriptions to match the order in the good.txt file. I did this because I wanted to make it easier for me to see the exact differences between the corresponding entries. Thankfully, for my minimal file it was just 12 ZIP entries. So, I started my editing, telling myself, “okay, so this file goes to position #1, that file goes to position #2…”, and I didn’t get very far before it suddenly dawned on me: the “problem” with my modified XD file could easily be the order of the ZIP entries!

Fixing a modified “bad” XD file manually

With my new theory, I just had to test it by manually creating a “corrected” XD file out of a “bad” one, with the “mimetype” file entry as the first one in the ZIP. You can follow the same steps:

1. Take your “bad” XD file, and unzip it to a folder using your favourite ZIP tool.

2. Then, create a new ZIP file, and add only the “mimetype” file. Also use a tool like 7-Zip or Total commander that allows you to choose “compression level = 0” to make sure the file is not compressed, only stored. By adding this file alone, before all the others, we are making it entry #1 in the ZIP file.

3. Now, you can add all the other files to the same new ZIP file. Here, you can do as you wish: the order of the rest of the files doesn’t matter, nor does their compression level.

In fact, I had to perform several tests, because I had no idea what Adobe XD expected. I first thought that it might be more than one file that must be at the “beginning” of the ZIP. But after a few rounds of tests, I concluded it was just this one “mimetype” file. (At least, in the latest version of Adobe XD, which I had available for testing.)

What were the Adobe XD developers thinking?

Having identified the root cause of the problem, I quickly found that this idea with an uncompressed “mimetype” file at the start of a ZIP container is not unique. In fact, the ebook file format EPUB, which is also a ZIP container, works exactly the same way: it also has a “mimetype” file, which also mustn’t be compressed and must be the first entry of the ZIP. I believe that the idea was to make it super quick and efficient for Adobe XD to perform a “file type check” to see if a file is really its own format, or perhaps something else.

So, the EPUB and XD developer teams did the exact same thing. Maybe the XD developers used EPUB as an inspiration, or both of them may have copied this technique from some other prior example. However, the EPUB developers took time to make their file format open, with a publicly available specification that anybody can read. For EPUB, the problem is still unintuitive and arguably not very user-friendly, but at least the information is out there. For the same problem with EPUB, if you can understand a highly technical file format specification document like the EPUB specification, you will be able to find the solution. And those geeks who understand it may be able to explain it to the rest of the users. With Adobe XD, the file format is not fully open and documented, so the world needed somebody like me who kept digging and just refused to give up before finding the solution.

The impact of a file format that resists “tampering”

One could argue that Adobe XD is a piece of proprietary software, and their developers and product managers are free to do whatever they want with it. They might not even want to make it too easy for users to read or hack their file formats, because they might be afraid that too much openness could hurt them and even benefit their competition.

However, once again, consider the use case of translation. As I said, you can’t expect translators to own an Adobe XD license just to be able to translate a few words inside an Adobe file. Professional translators (and translation teams) work in professional translation tools, and any file format that ever gets translated should be open enough to enable a basic level of external processing or editing in a translation tool.

According to analysts in the field, the translation industry had an estimated market size of USD 26.6bn in 2022. If you have a software product that makes it more difficult for people to translate its files, you are limiting the software product’s chances of success by causing friction and lost hours and hairs for everybody who needs to translate the files. Translation companies big and small will dread your product instead of working happily and efficiently with it.

And, of course, translation is just one industry and one important use case. There could be a million other valid reasons for your users to want to process Adobe XD files. And if you limit the interoperability of your tool with the rest of the world by making it way too tricky to modify the files, then you are causing an unknown amount of harm to your software product. There might be thousands of cases where customers abandon your product or never start using it because they can’t perform some crucial task with it, or can’t make it work with their own software systems or other third party software they also use.