Few would argue with the statement that XML had an immense impact on the development community, influencing almost every area of computer science, from XML-based game files to financial data exchanged between various distributed Wall Street trading systems.

XML, in and of itself, however, is a text-centric medium. Even domain-specific applications—such as RSS, which uses XML as a means to syndicate information—are essentially limited to propagating text information. Any reference to binary data typically takes the form of a link pointing to an external resource to be parsed, validated, and presented by the RSS reader, or in a more general sense, by the targeted XML-interpreting application.

But what if you wanted to include actual binary data in your XML document? Well, your options are limited...but there are options. Let's examine some of these options with a working example. Figure 1 presents the one picture that you just can't wait to include in your next XML document.

Figure 1: What if your XML document requires an image?

The first, and probably most obvious approach of including binary data such as this image in your XML document is to do exactly what RSS and many other XML derivatives are doing, which is to not include the binary data, per se, but instead include a link pointing to an external resource where the image can be found (Figure 2):

Figure 2: Perhaps the solution is to include a link pointing to an external resource where the image can be found. (Click images to enlarge.)

This works fine with an RSS document in which the link points to a valid URL containing the image. But it isn't difficult to see the limitations in this approach. When sending XML data in a domain where external URLs are not feasible, such as when financial data needs to be sent from one financial institution to another, this approach breaks down. The receiving party cannot click on a link to access the financial data residing on the sending server. In essence, this would remove the entire purpose of sending the XML data in the first place. Even with RSS, images are sometimes deleted from the server, and older RSS messages containing URL links to those images end up full of broken links.

So, at this point, you've come to the conclusion that URL insertion is simply not for you. You need to actually embed the binary data into the XML document. So how do you do that? Well, why can't you just stick the raw binary data composing the picture directly into the XML document (Figure 3)?

Figure 3: This code contains raw binary data.

The problem with doing this should be fairly obvious. Binary data can contain anything. In particular, it can contain characters that are treated specially by XML parsers, such as
So we can't just place the binary data directly into the XML document. Now what? Well, at this point some XML pundits will point out that this is one of the circumstances where the XML tag should be used (Figure 4).

Figure 4: Is this a job for the XML tag?

Indeed, this is the approach taken by many folks seeking to have XML documents contain data that typically has no place in an XML document. The tag is indeed meant to contain any data that should be effectively ignored by the XML parser. But the problem here is that while we get rid of the problem of having indicates to the parser that the section is over. Because of this, tags cannot be nested. And because of this, while we effectively minimized the chances of corrupting the XML document with binary data, we did not entirely eliminate it; characters like (and how can you make sure it does not?), we are in the same hole as we were before. Still, remains one of the more popular methods of including "additional" data in an XML document.

Finally, another common approach to embedding binary data in XML documents is Base64 encoding (Figure 5).

Figure 5: Ah, here's the answer! Base64 encoding!

Encoding your binary data in base 64 "maps" the binary data to printable characters, ensuring that bad characters do not show up in your XML document. This removes the threat of corrupting the receiving parser, but it does have drawbacks in terms of size and space. Base64-encoded data is about 33% larger in size than the original data. In terms of time, you also have to take into account the fact that the data has to be encoded on one side and subsequently decoded on the other. Still, if stability and accuracy take precedent to efficiency and space requirements, one cannot go wrong with Base64 encoding, especially since so many programming languages provide libraries for accomplishing this task, and there are many open-source and freeware standalone tools available as well.

Andrey Butov works as the lead developer for Antair Corporation. He can be contacted at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it .