Thursday, February 22, 2024

Serving up Base64-encoded Custom Fonts

Serving up Base64-encoded Custom Fonts

There is some debate among web developers about the performance advantages of embedding images and fonts directly into the page using Base64 encoding. Some contend that it improves performance by keeping http requests to a minimum while others argue that the file bloat caused by base64 encoding offsets any gains achieved by cutting down on the number of server requests. Moreover, opponents of direct embedding assert that after the first page load, font files should be cached just like the CSS files that declare them and therefore immediately available. Disagreements aside, a situation may arise where you don’t have much choice in the matter. For instance, if you don’t have a means to upload files to the server or if you are working behind a firewall – like I do in my day job – that blocks storage servers. Should the conditions present themselves for you to turn to embedded fonts, knowing how it’s done will make the whole process much smoother.

What is Base64 Encoding?

Base64 is an encoding scheme that converts binary data into text characters. It’s required where a protocol may interpret binary data as control characters (e.g. a modem), or interpret certain patterns as a special character combination. For instance, FTP translates line endings. Historically it has been used to encode binary data in email messages where the email server might modify line-endings. In HTML, it is necessary to encode the data to avoid characters like ‘<‘ and ‘>’ being interpreted as tags.

Base64-encoded data in embedded into the HTML via a data URL scheme. It was defined in the Internet Engineering Task Force’s RFC 2397 specification. Although the IETF published the Data URL specification in 1998, it was never formally adopted as a standard. Nevertheless, the HTML 4.01 specification referenced the data URI scheme, which, despite years of neglect, led to all modern browsers implementing some degree of support for Data URLs.

The URLs are in the following format:

  • The <mediatype> is an Internet media type specification (with optional parameters.) – i.e. “text/plain;charset=UTF-8”, “image/gif”, “application/octet-stream”, etc. If <mediatype> is omitted, it defaults to “text/plain;charset=US-ASCII”.
  • The “;base64” string identifies the data as base64-encoded.
  • The data, separated from the preceding part by a comma (,). The data is made up of multiple sequences of eight bits called octets represented as characters. Permitted characters within a data URI include the ASCII characters for the lowercase and uppercase letters of the modern English alphabet, as well as Arabic numerals. Octets represented by any other character must be URL-encoded (also known as percent-encoding), i.e. “%26” for an ampersand (&). Data URIs encoded in Base64 may contain whitespace for human readability.

The following embedded image renders a red dot in the bowser:

<img src="/wp-content/uploads/2021/04/e7e44af6f5522eb36e8fe4f2ac4f25dd.png
9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

Here is the resulting image.

Red dot

Applying Base64 Encoding to Fonts

Unlike images, fonts are not set on a tag attribute, but on the CSS @font-face rule. As we saw in the How to Appropriate Custom Fonts from other Websites tutorial, the CSS @font-face rule’s src property supports the use of embedded Base64 data:

@font-face {
 font-family: Bazar;
 src: url(data:font/ttf;base64,AAEAAAATAQAABAAwR1BPU+Df...

Factors to Consider when Embedding Fonts

As alluded to at the start of this tutorial, although employing embedded fonts does cut down on the number of HTTP requests, there are other factors that come into play:

  • Fonts may not be cached if you include them in your main HTML document – especially if it is dynamically generated. The base64 encoded data is treated as part of the resource it’s embedded in (e.g. the HTML or CSS file) so, if the main page cannot be cached, then the fonts wont either. Therefore, it is best to place embedded fonts within an external CSS file so that it is referenced using a standard Resource Identifier. That should result in the caching of the CSS file, along with the font data within it.
  • Base64 encoding bloats image sizes by about 33% (on third), although that figure can vary.
  • Base64-encoded and/or gzipped data may possibly take longer to process than binary data. This might be especially pronounced on mobile devices, which have more limited CPU and memory.

Creating Data URIs

So now that you understand how to use data URIs in your web pages, how do you actually create them? There are a few different options available.

Use an Online Converter

Fontsquirrel’s online webfont generator is a great free tool. Just upload a .ttf or .otf file, choose your settings and click a button to create a whole kit. If you select the Base64 Encode option, it will even generate the CSS file for you. Here are the pertinent settings:


Using the Base64 Command

In OS X or Linux, the built-in base64 command in Terminal/shell will generate the Base64-encoded string for you:

$ base64 myfont.ttf > myfont64.txt


Have you utilized Base64-encoded fonts in your web pages. What were your impressions of it? Leave a comment below and tell us about it!

Rob Gravelle
Rob Gravelle
Rob Gravelle resides in Ottawa, Canada, and has been an IT guru for over 20 years. In that time, Rob has built systems for intelligence-related organizations such as Canada Border Services and various commercial businesses. In his spare time, Rob has become an accomplished music artist with several CDs and digital releases to his credit.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Popular Articles