Emoji Rendering Issue: Inconsistent Flag Emoji Rendering Across WordPress Self-hosted, WordPress.com, Jetpack Reader, Mobile, and Desktop Environments

[Jiwoon-Kim]

Description

Issue Body (Translated)

Self-hosted WordPress
https://travel-in-busan.com/topics/it/wp/wordpress-useful-links/
Flag emoji https://s.w.org/images/core/emoji/15.1.0/svg/1f1f0-1f1f7.svg : image loaded from org site
https://wordpress.com/reader/feeds/162495554/posts/5670302405 - WordPress Reader
Flag emoji https://i0.wp.com/s.w.org/images/core/emoji/15.1.0/72x72/1f1f0-1f1f7.png?ssl=1 loaded as PNG via Jetpack.
Problem: On mobile, it appears very large, not matching the font size. (It was like this until just now, but suddenly started rendering as a system font emoji on mobile.)

WordPress.com Blog
https://kowporg.wordpress.com/2025/05/17/wordpress-useful-links/
Flag emoji https://s0.wp.com/wp-content/mu-plugins/wpcom-smileys/twemoji/2/svg/1f1f0-1f1f7.svg loaded from com site
https://wordpress.com/reader/feeds/169602085/posts/5670149998
On desktop: 🇰🇷 rendered via system font.
On Windows 11, flag emoji rendering not supported (regional indicator symbols show as "KR")
On mobile (Samsung Galaxy), rendered via system font emoji — expected Noto Color Emoji on Android, but appears to be Samsung’s custom emoji.

https://kowporg.wordpress.com/2025/05/17/emoji-debug/
On Windows OS, flag emoji loaded via SVG
https://wordpress.com/reader/feeds/169602085/posts/5670432387
All rendered via system font, but flag emoji not rendered on Windows.

At https://kowporg.wordpress.com/2025/05/17/emoji-debug/
On Windows OS, flag emoji is loaded via SVG.
Additionally, when viewed on desktop, the spacing between emojis is inconsistent — some emojis break to the next line unexpectedly, while others overflow beyond the post template layout and continue in a single line.

This issue occurs inconsistently depending on emoji type and rendering method (SVG image vs system font emoji), and affects overall post layout appearance.

Summary of the current situation:
Between WordPress self-hosted / WordPress.com / Jetpack Reader / mobile / desktop environments, the emoji fetch paths, formats, and rendering methods differ subtly.
Especially for flag emojis, behavior changes based on OS + browser + WordPress setup.

WordPress Self-hosted vs WordPress.com Reader
Self-hosted: core emoji script calls SVG emojis via wp-emoji-release.min.js and outputs them with <img> tags.
WordPress.com Reader: Depending on the situation, prioritizes browser system font emoji rendering.
→ Windows 11 doesn’t support flag emoji (Regional Indicator Symbol 🇰🇷) in its system font, so it displays as "KR"
→ Android Galaxy devices apply Samsung emoji

Jetpack Reader and CDN caching path difference
Jetpack processes image paths via https://i0.wp.com/ proxy.
→ Loads PNG emojis with <img> tags, ignoring font size and displaying in original size
→ This was the reason why it appeared large on mobile

Browser / OS / Theme / Caching issues
Emoji rendering is heavily affected by caching.

Step-by-step reproduction instructions

/

Screenshots, screen recording, code snippet

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

[dangermattic]

Thanks for reporting! 👍

[Jiwoon-Kim]

Also, it would be good to standardize these emoji rendering behaviors now because in the future, if WordPress Reader expands to support Fediverse feeds (ActivityPub integration), it would need to handle non-standard emoji reactions from platforms like Misskey.

Currently, Misskey uses custom emoji reactions via non-standard ActivityPub extensions, and inconsistent emoji rendering between WordPress Reader, Jetpack, and self-hosted sites could cause display issues and interoperability problems when integrating with Fediverse content.

Standardizing emoji rendering paths, formats, and fallback behaviors would make future integration smoother and more reliable.

#24516

Standardizing emoji rendering will benefit both current and future WordPress ecosystems.

[Jiwoon-Kim]

Also, it would be good to standardize these emoji rendering behaviors now because in the future, if WordPress Reader expands to support Fediverse feeds (ActivityPub integration), it would need to handle non-standard emoji reactions from platforms like Misskey.

Currently, Misskey uses custom emoji reactions via non-standard ActivityPub extensions, and inconsistent emoji rendering between WordPress Reader, Jetpack, and self-hosted sites could cause display issues and interoperability problems when integrating with Fediverse content.

Standardizing emoji rendering paths, formats, and fallback behaviors would make future integration smoother and more reliable.

#24516

Standardizing emoji rendering will benefit both current and future WordPress ecosystems.

---

커스텀 이모지는 각자 서버 리소스 사용한다 쳐도 역시 시스템 이모티콘 선택기로는 못하는 영역이라 결국 구텐베르크에 커스텀 이모지 셀렉터창 구현 해야할거같은데.. https://wiki.ubuntu.com/DesktopTeam/Emoji#:~:text=Ubuntu%20uses%20Google's%20Noto%20Color%20Emoji%20font%20as,updated%20in%20October%202024%20to%20support%20Unicode%2016.0.

---

Right now, each platform (self-hosted WordPress, WordPress.com Reader, Jetpack Reader, desktop, mobile) handles emoji rendering inconsistently. This inconsistency especially affects flag emojis and custom emoji integration.

Since system emoji pickers are entirely dependent on OS and browser implementations (for example, Ubuntu uses Noto Color Emoji, Windows uses Segoe UI Emoji, Samsung devices use their own emoji font), we cannot control how those are rendered within WordPress content.

If we intend to implement custom emoji reactions in WordPress via ActivityPub extensions — similar to how Misskey or Mastodon handle non-standard custom emojis using tags — we need to first standardize how WordPress handles emojis across its ecosystem.

That includes:

Defining a custom emoji selector inside Gutenberg editor.

Separating between:

System emoji picker (native emojis via OS keyboard/input)

Custom emoji selector (self-hosted emojis via )

CDN-hosted emoji sets (like Noto Emoji or Twemoji as fallback images)

Standardizing emoji names / shortcodes (:laughing:, :korea_flag:) to maintain compatibility with ActivityPub custom emoji payloads.

Defining a consistent rendering approach in Reader, Jetpack, and external feed contexts to avoid discrepancies like oversized PNGs or missing flags.

Without this, it’ll be difficult to later support cross-platform emoji reactions when expanding WordPress Reader into a federated ActivityPub feed, where Misskey and Mastodon already rely on this -based custom emoji model.

Proposal:
Create a prototype for a Gutenberg Emoji Picker Block with:

Tabs for System Emojis and Custom Emojis

Integration with the site’s emoji asset library (like media uploads or CDN-hosted sets)

Standardized shortcode mapping for ActivityPub reactions

If you like, I can draft a spec doc for this — including a JSON format for custom emoji reactions and a compatibility table with existing Fediverse implementations.

Would you be interested in that?

[Jiwoon-Kim]

The only consistently available custom emoji-like assets on WordPress.com are the logo and Wapuu.
If a custom emoji picker is implemented for Gutenberg in the future, it could ship with a default Wapuu emoji pack.

[Jiwoon-Kim]

If WordPress implements a custom emoji feature, it could also create new business opportunities.
In Korea, these are called "emoticons," and there's an active market of character designers creating custom emoji packs.
If WordPress could absorb that market, it would expand both its revenue models and ecosystem.

This could even open up collaboration opportunities with brands like Sanrio or Pokémon through WordPress.com.
In turn, it could pave the way for unique community events — for example, integrating WordPress.org meetups with Pokémon GO's API for location-based marketing campaigns

Imagine wp.org events promoted through Pokémon GO’s API — location-based marketing meets open-source culture. It’s closer than you think.