Microsoft has begun rolling out support for Emoji 16.0 in Windows 11 24H2 through the August 2025 optional preview update KB5064081, but users who open the Emoji Panel (Win + .) expecting to find the new icons will be disappointed. The panel, which serves as the primary entry point for inserting emojis, does not yet list any of the seven new emoji characters—including the much-anticipated Face with Bags Under Eyes, Fingerprint, and Shovel—leaving them accessible only through workarounds or in apps that query the updated system font directly. This disconnect is the latest chapter in a long-running saga of fragmented emoji support across Windows.
Emoji 16.0 itself is a deliberately small release, approved by the Unicode Consortium alongside Unicode 16.0 on September 10, 2024. It adds eight new concepts: seven standalone emojis (Face with Bags Under Eyes, Fingerprint, Splatter, Root Vegetable, Leafless Tree, Harp, Shovel) and the Flag: Sark sequence, bringing the total recommended-for-interchange emoji count to 3,790. The set was formalized months ago, and rival platforms like Android and iOS have already integrated them into their keyboards. Microsoft, however, is following its familiar pattern of staggered deployment.
The August 29, 2025 preview cumulative update, KB5064081 (build 26100.5074), updated the Segoe UI Emoji font family with Fluent-designed glyphs for the new code points. The same assets were later bundled into the September Patch Tuesday rollout. Once installed, any application that uses the modern DirectWrite text rendering API and queries the system emoji font should be able to display the new emojis. Yet, many older UI surfaces and apps that rely on legacy rendering engines or their own font stacks continue to show the dreaded missing-glyph rectangle.
Real-world testing across Windows 11 24H2 systems reveals a patchwork of support. Notepad, OneNote, Microsoft Word, PowerPoint, and Teams all render the Emoji 16.0 icons correctly—but only within their main editing panes. The title bar of Notepad, rendered by the legacy Win32 GDI subsystem, displays blank squares for the same code points. Similarly, Edge’s address bar, Windows Search, and File Explorer’s UI surfaces fail to show the new emojis because those components rely on GDI or WebView controls that do not leverage the updated Segoe UI Emoji font. Outlook desktop, built on the older RichEditD2D engine, cannot display them either.
Web applications add another layer of inconsistency. Google Docs, Sheets, and Keep stick to Google’s own Noto Color Emoji font, which has not been refreshed on Windows for Unicode 16.0. Gmail on the web, however, shows the new emojis—likely because it taps into a different font pipeline. Facebook’s web client renders them, while Instagram and X (formerly Twitter) do not. WhatsApp’s desktop and web clients excel here, shipping their own independent emoji sets and therefore showing all new glyphs, including Flag: Sark, regardless of the underlying Windows version.
To understand why a system-level update delivers such uneven results, one must look at how Windows handles text rendering. Emoji are plain Unicode code points; to become visible, an application must map each code point to a glyph in a font file. On Windows, the official emoji font is Segoe UI Emoji, part of the Fluent design family. Modern apps built on DirectWrite—the GPU-accelerated API introduced with Windows 7—gain access to color font features and the latest glyphs as soon as the font is updated. Legacy applications, however, often use the older GDI or Win32 APIs, which lack robust color glyph support and rely on separate font fallback logic. These paths are rarely touched during servicing updates, so they remain stuck with outdated emoji sets.
This architectural debt is the root cause of the current fragmentation. Even within the same app, different UI surfaces may use different rendering stacks. The result is a jarring experience: copy an emoji into Notepad and it appears; paste it into the title bar and it vanishes. For web apps, the situation is even more complex, as they can override system fonts entirely with bundled web fonts or server-side image sets, insulating themselves from OS-level changes.
The Emoji Panel’s lag is a separate but related issue. The panel (Win + . or Win + ;) is a curated UI that draws its icon grid and search index from an internal dataset, not directly from the Segoe UI Emoji font file. Even after the font is updated on disk, the panel’s metadata—the list of available emojis, their names, and their keywords—must be separately refreshed. Microsoft frequently stages such UI updates behind feature flags, rolling them out slowly to monitor telemetry and avoid regressions. The same pattern was observed with Emoji 15.1: the font arrived in Insider builds in late 2023, but the panel didn’t reflect the changes until June 2024. Based on that precedent, users can expect a full panel update for Emoji 16.0 to arrive in a cumulative patch within the next few months, though no official date has been announced.
For those unwilling to wait, several workarounds exist. Installing the latest optional cumulative update (KB5064081 or later) ensures that the font assets are present, enabling at least partial rendering in DirectWrite-capable apps. Power users can copy the desired emoji from a reference site like Emojipedia or the Unicode charts and paste them directly into applications that support the updated font—Notepad, Word, or Teams, for instance. Apps that bundle their own emoji fonts, such as WhatsApp or Telegram, remain the most reliable way to both view and send the new icons across platforms.
The situation underscores both the strength and the weakness of Microsoft’s emoji strategy. The Fluent design is visually polished and highly regarded, and when it works, it offers a consistent look across Microsoft’s ecosystem. But the underlying rendering infrastructure—a patchwork of GDI, DirectWrite, RichEdit, and WebView—defeats that consistency at every turn. Users are left with an inconsistent experience that erodes trust and undermines cross-platform communication. For enterprise customers, where emoji are increasingly used in internal messaging and collaborative tools, the unpredictability can cause real confusion.
Security-wise, the update is benign; it introduces no new attack surface beyond the usual risks of any font update, which are mitigated by standard Windows Update signing and validation. The larger operational risk is perceptual: shipping font files without immediately enabling the panel makes the release look incomplete, fueling user frustration. Microsoft would do well to better synchronize font and panel rollouts, publish clear documentation for IT admins about which rendering surfaces are affected by each KB, and encourage its own first-party apps to unify on modern rendering pipelines. A diagnostic tool or Settings page that shows which apps can render the latest emojis would also be a welcome addition.
In the meantime, the arrival of Emoji 16.0 on Windows 11 24H2 is a story of half measures. The new glyphs exist on disk, but they remain hidden from the tool most users rely on to find and insert them. The full promise of Unicode 16.0 on Windows will be realized only when Microsoft bridges the gap between its emoji design ambitions and the aging rendering architecture that still underpins large swaths of the operating system.