Pop quiz: what emoji do you see below? [1]
Depending on your browser and operating system, you might see:
- The flag of Martinique
- The old flag of Martinique (which kinda looks like the Quebecois flag)
- The enigmatic initials “MQ”
From left to right: Safari on iOS 17, Firefox 130 on Windows 11, and Chrome 128 on Windows 11.
This, frankly, is a mess. And it’s emblematic of how half-heartedly browsers and operating systems have worked to keep their emoji up to date.
What’s responsible for this sorry state? I gave an overview two years ago, and shockingly little has changed – in fact, it’s gotten a bit worse.
In short:
- Firefox bundles their own emoji font (great!), but unfortunately, thanks to turmoil at Twitter/X, their bet on Twemoji has not shaken out too well, and they are two years behind the latest Unicode standard.
- Windows 10 users (i.e. 64% of Windows as a whole) are stuck five years behind in emoji versions, and even Windows 11 is still not showing flag emoji, which Microsoft excludes for some mysterious reason. (Geopolitical skittishness? Disregard for sports fans?)
- Safari has the same fragmentation problem, with multiple users stuck on old versions of iOS, and thus old emoji fonts. For example, some 3.75% of iOS users are still on iOS 15, with only 2022-era emoji. [2]
As a result, every website on the planet that cares about having a consistent emoji experience has to bundle their own font or spritesheet, wasting untold megabytes for something that’s been standardized like clockwork by the Unicode Consortium for 15 years.
My recommendation remains the same: browsers should bundle their own emoji font and ship it outside of OS updates. Firefox does this right; they just need to switch to an up-to-date font like this Twemoji fork. There is an issue on Chromium to add the same functionality. As for Safari, well… they’re not quite evergreen, and fragmentation is just a consequence of that. But shipping a font is not rocket science, so maybe WebKit or iOS could be convinced to ship it out-of-band.
In the meantime, web developers can use a COLR font or polyfill to get a reasonably consistent experience across browsers. It’s just sad to me that, with all the stunning advancements browsers have made in recent years, and with all the overwhelming popularity of emoji, the web still struggles at rendering them.
Footnotes
- I’m using Codepen for this because WordPress automatically replaces native emoji with
<img>s, since of course browsers can’t be trusted to render a font properly. Although ironically, they render the old flag (on certain browsers anyway): 🇲🇶 - For posterity: using Wikimedia’s stats for August 12th through September 16th 2024: 1.2% mobile Safari 15 users / 32% mobile Safari users = 3.75%.
Read the Tea Leaves 
Posted by Almog on September 19, 2024 at 9:18 PM
Actually i’m on ios and the flag I see in the end of the article is still the new one, so I think the first footnote might not be accurate.
Posted by Nolan Lawson on September 20, 2024 at 9:04 PM
Interesting, it looks like they do some kind of feature detection and only inject the
<img>s in certain browsers. In Firefox I see an<img>pointing at a picture of the old flag, whereas in Chrome and Epiphany browser I see just a plain text character (which renders the new flag on my OS, Ubuntu).Posted by Aleteoryx on September 23, 2024 at 7:51 AM
i believe the windows bug is down to their font shaper not supporting multi-codepoint emojis, as flags are embedded as 2-letter ISO country codes, using codepoints from a special block. the same thing happens with the transgender flag emoji IIRC, as it’s made of the trans symbol and a generic flag codepoint. which is to say, it’s not just failure to support flags, it’s failure to support a critical component of how emojis are encoded in general!