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.