W3C Incremental Font Transfer (IFT) is now a candidate recommendation

Dave Crossland

Big news for web fonts (especially CJK) 

https://www.w3.org/news/2025/w3c-invites-implementations-of-incremental-font-transfer/

James Puckett

Now web sites can shave 1.5KB off a font to speed up downloading 5MB of tracking scripts!

Albert Creus

Great news to free from Noto's omnipresence in non-latin world!

Thierry Blancpain

Based on the Github explainer for this it sounds like fonts will need extra tables linking to additional fonts for further scripts or extended character sets. Or are these tables written into the (partially downloaded) font by the browser/client?

John Hudson

The Patch Map Table is added when the font is prepped for Incremental Font Transfer, so this is a server side operation, prior to serving the first part of the font.*

IFT has taken a really long time to get to this current candidate recommendation stage in large part because several different approaches were explored, tested, and rejected for one reason or another. IFT as spec’d is almost completely different from the first version, and one of the main differences is that the font needs to undergo server side preprocessing of patches in readiness to be served, rather than the patches being dynamically determined from the client side. In this model, the server gets a patch request from the client, based on the patch map.

Dynamic patches are a much more alluring concept, but they introduce a lot of complications and performance issues, as well as some potential security and privacy concerns.
_____

I think font foundries need to familiarise themselves with this technology and determine whether they need to update their EULAs. Given that IFT involves additions to the font data, it seems prudent to explicitly permit and limit this, in the same way that EULAs permit and limit subsetting.

Stuart Sandler

@John Hudson might this be a potential method to obscure web fonts from being pirated potentially by splitting the sources and recombining them correctly to render?

John Hudson

If you mean obscuring them on the server side, possibly, although the first served subset contains the patch table with all the information necessary to grab the other parts.

Roel Nieskens

I'm excited to see this advance! I think it will be a new chapter in the webfonts saga, even for Latin fonts.

As I understand the spec, at the very least for Latin fonts it can offer a failsafe for missing characters in a smoother way than Unicode chunking can. On top of that, selective serving of extra OpenType features (hinting, alternatives, etc.) or variable axes.

I expect first adoptions to go overboard with everything IFT offers, and that'll be an interesting time. Abusing it for overaggressive subsetting, inefficient patches, the license breaking that John mentioned, and everything else. I'm also curious what can be done by initially serving lean fonts, then applying pre-fetched patches. Idiotic overkill, or a way to better control font loading? All fun stuff to noodle with.

Also, next to CJK, emoji and icon fonts... It opens new possibilities for all those large fonts. I understand the webfont market is basically non-existent in Asia, I wonder how this will change it.

Jongseong Park

There is a market for webfonts in Korea, Sandoll Cloud being the big (only?) player. They use dynamic subsetting, though I'm not familiar with the technical details.

Dave Crossland

The main benefits I see for the web browsing general public is primarily faster speeds of web page loads, and secondarily, experiencing more sophisticated typography,  because "selective serving of extra OpenType features (hinting, alternatives, etc.) or variable axes" really means simplicity for web developers - they integrate a font family as a family, without preselection of features, and use whatever the family has to offer, and web browsers only download what they need as they need it. I hope this means that devs will use more of the depth of features within families

Johannes Neumeier

John Hudson said:

...

I think font foundries need to familiarise themselves with this technology and determine whether they need to update their EULAs. Given that IFT involves additions to the font data, it seems prudent to explicitly permit and limit this, in the same way that EULAs permit and limit subsetting.

The spec literally mentions this, too:

This ["lossless" encoding] may be important for cases where a foundry or other rights-owner of a font wants be confident that the encoding and transfer of that font using IFT will not change its behavior and therefore the intent of the font’s creators. Licenses or contracts might then include requirements about IFT conformance, and situations in which re-encoding a font in WOFF2 format is de facto permissible due to its content-neutrality might also permit IFT encoding of that font.

Johannes Neumeier

I've been wondering if this opens up the door for a font serving service akin to a Typekit or similar. Presumably the browser support will roll out faster than applicable hosting solutions that automate the IFT encoding/patching, and can accommodate the request overhead. So there may be a time when this is supported on the user side, but developers wanting to use IFT might struggle to host them; this is just my hunch.

Edit: That is to say: It would be nice if such a service offering came from within the type industry.

Roel Nieskens

@Johannes Neumeier I suppose one could start with "static patch-hosting" where you manually chop up the font in patches according to a set of rules, kinda like you would do now when applying Unicode chunking. Maybe that'll suffice for most situations, and foundries could even offer pre-made patch configurations.

But something server-side would be welcome for more advanced control. If your logs show every single user fetching the main font and always the same small patch right after, then you know that patch should really become a part of the main font. That could be automated.

Note that I'm thinking about this from the Latin angle mostly, so I imagine a patching recipe for CJK fonts will look different. I can imagine you can't just blindly keep adding patches to the main font without a good "garbage collection" every once a while, especially on sites with dynamic content.

Dave Crossland

Johannes Neumeier said:

I've been wondering if this opens up the door for a font serving service akin to a Typekit or similar. 

I don't get it  

Presumably the browser support will roll out faster than applicable hosting solutions that automate the IFT encoding/patching

As John flagged in his first comment, the IFT 'encoding' process is a one-time operation, similar to the one-time operation to convert/encode a TTF or OTF file into a WOFF or WOFF2 file. There's nothing new/different/unusual/interesting about hosting the results of either of these operations.

Earlier ideas for IFT presumed to use a new protocol (like HTTP or FTP) which of course presumed a new hosting solution, likely a (set of) reference plugin(s) to popular web server(s). But once browser support rolls out to just three browser engines (Chrome/Edge/Opera/etc's Chromium, Safari's WebKit and Firefox's Gecko) then any web developer can stick up their offline/pre-processed 'encoded' files in their normal web server, and they are good to go. Or, more likely given what we've all seen for 15 years, any web developer will find that as they first obtain their font files from their distributor, that they have received pre-converted files.

https://github.com/w3c/ift-encoder is the reference implementation of the encoding process described in the itf spec, and that software is likely to be what distributors use to generate files to send to their distributees. 

So maybe I'm missing something, but what struggles do you see the developers, who are wanting to use IFT, encountering? 

Roel Nieskens

@Dave Crossland Do you think a one-size-fits-all IFT font will be the norm? Is that what Google Fonts will do? I can imagine different versions for different situations, kinda like you're doing now for different browsers and OSes. What secret sauce are you cooking up?

For example I could see Greek being embedded in the initial font or being a patch, depending on whether your site is in Greek, or in English with the rare possibility of including a Greek word.

Johannes Neumeier

Dave Crossland said:

Earlier ideas for IFT presumed to use a new protocol (like HTTP or FTP) which of course presumed a new hosting solution, likely a (set of) reference plugin(s) to popular web server(s). But once browser support rolls out to just three browser engines (Chrome/Edge/Opera/etc's Chromium, Safari's WebKit and Firefox's Gecko) then any web developer can stick up their offline/pre-processed 'encoded' files in their normal web server, and they are good to go. Or, more likely given what we've all seen for 15 years, any web developer will find that as they first obtain their font files from their distributor, that they have received pre-converted files.

Oh, my misunderstanding then. I originally thought this was where the spec moved towards to, but when skimming yesterday it seemed to me this serving would still be dynamic or somehow require the server to need to be able to handle special requests. Need to read more closely, again.

Dave Crossland

I would expect it wouldn't really matter if Greek is embedded in the initial font or is a patch, because if the site is in Greek and its a patch, it will immediately load the patch on the 1st page, and the time to apply the patch is so small; and if the site is English and then the 10th page in the site includes a Greek word, only then is the patch loaded. But sure, the time is non zero and a hyper optimization would be better that way. 

However, I sent this thread to my Google Fonts team engineering colleague, Garret (who led the spec development) and he clarified the current state of dynamic vs static patches:

"The spec was developed primarily with static patches in mind, so as Dave said run a font through the encoder to get an initial set of font + patches files, and then just host these files as per usual.

However, dynamic patches are still possible if a web service wants to do that! The initially generated font could contain links to patches where the URL contains all of the info needed for the server to generate that patch on the fly, much like what we do with fonts.googleapis.com/css?family=Lobster&text=abc

Advanced hosting services can take a hybrid approach where frequently used patches are pre-cut and hosted as static files, and then low frequency patches are left for dynamic generation (but are still transferred using regular HTTP)."

Johannes Neumeier

Dave Crossland said:

However, I sent this thread to my Google Fonts team engineering colleague, Garret (who led the spec development) and he clarified the current state of dynamic vs static patches:

"The spec was developed primarily with static patches in mind, so as Dave said run a font through the encoder to get an initial set of font + patches files, and then just host these files as per usual.

However, dynamic patches are still possible if a web service wants to do that! The initially generated font could contain links to patches where the URL contains all of the info needed for the server to generate that patch on the fly, much like what we do with fonts.googleapis.com/css?family=Lobster&text=abc

Thanks for the clarification. I guess I just looked at my browser requests in the demo implementation and saw a ton of *.ift_tk patch downloads and assumed they would be dynamic from the webserver. Alas, each request is just a plain blob sent over HTTP and the ift_tk files are presumably spit out by the encoder on encoding, and need to be placed on the server (or whereever the URLs in the IFT tables specify). 

I reckon this could also mean foundries could distribute encoded standalone woff2 files where the patches are linked to their own hosted service/domain, so clients would merely need to host the woff2 files, just as with unencoded woff2 files, and get a seamless developer and end user experience? (Of course, there is this to consider: "Load patch file: specifies the use of [FETCH] in implementing web browsers and matches the CORS settings for the initial font load. As a result cross-origin requests for patch files are disallowed unless the hosting service opts in via the appropriate access control headers.")

Advanced hosting services can take a hybrid approach where frequently used patches are pre-cut and hosted as static files, and then low frequency patches are left for dynamic generation (but are still transferred using regular HTTP)."

It seems to me that any and all patches are "pre-cut and hosted as static files", generated on the fly or not. I think from an adoption and distribution point of view, getting a zip file with a woff2 file plus 50 odd patch files will need some education on how to use those.

Roel Nieskens

Saving that extra round trip to the server every single time the font is fetched doesn't seem like a hyper optimization. If you know a patch would be loaded every single time the page is requested, it'd make sense to include it in the initially generated font. Even with HTTP/2 and other network optimizations. Unless I'm missing a piece of IFT that further optimizes that?

I like Garret's ideas, I hope GF and other hosting services will implement a smart dynamic system.

For CJK, will there likely be a generic default initial font with a default set of patches? Or would that differ per language, region, site or even page? Would an initial font include for example simplified Chinese and traditional Chinese?

John Hudson

I think from an adoption and distribution point of view, getting a zip file with a woff2 file plus 50 odd patch files will need some education on how to use those.

I think implementing IFT for a font is going to be primarily a web developer responsibility. There are too many site-specific factors for a font foundry to be able to pre-build patches as part of their webfont packages for customers.

Encoding IFT initial fonts and patches is something that I suspect AI would be really good at, and potentially could be re-run automatically to improve performance for a given site—even one featuring dynamic text—over time.