If you’re looking to speed up your site as fast as possible you may have noticed the wp-emoji-release.min.js file loading on all of your pages. This is WordPress’ emoji support which is enabled by default since WordPress 4.2.
- Disabling emoji support does not stop emojis working. Every modern browser renders them natively.
- The saving is smaller than most guides claim: about 1.3 KB of inlined JavaScript, not the 22 KB figure you will see quoted.
- Since WordPress 6.3 the loader caches its browser test and runs it in a background Worker, so the one real cost it used to have is mostly gone too.
- WordPress stopped adding the
s.w.orgDNS prefetch in version 6.0, so snippets that filter it out are removing nothing. - Most snippets miss the oEmbed hooks, so the emoji script keeps loading inside embed iframes.
- A plugin and a code snippet do the same job. Use the snippet if you would rather not add a plugin for a dozen lines of code.
That script is a compatibility layer from 2015. It tests whether the browser can draw emoji and, if it cannot, swaps every emoji on the page for an image. Modern browsers pass the test, so on most devices it does almost nothing, and the honest case for removing it is smaller than the page speed guides suggest. It is still worth doing, and this guide is straight about why.
Most WordPress sites do not need the emoji fallback at all, so we recommend you disable emojis in WordPress.
Many performance plugins (like WP-Rocket) will also give you the option to disable emojis. If you aren’t currently disabling Emojis this guide will show you a plugin to disable emojis in WordPress. I’ll also show you a code snippet to use in your functions.php to disable Emoji support as well.
What You Actually Save
Worth being straight about the numbers, because most guides on this topic are not.
WordPress ships two emoji files. wp-emoji-loader.min.js is about 3 KB raw and 1.3 KB gzipped, and it is inlined into the head of every page. wp-emoji-release.min.js is the big one at roughly 22 KB raw and 5.3 KB gzipped (both measured on WordPress 7.1), and it is the number everyone quotes.
Here is the part that usually gets left out: the big file only downloads if your visitor’s browser fails the emoji support test. The loader draws emoji to a canvas and compares the pixels to work out whether the browser can render them natively. Every current browser passes, so on a modern device that 22 KB file is never requested. Quoting it as your saving is not accurate.
What you genuinely remove is the 1.3 KB of inlined loader and the support test it runs. Older guides add a DNS prefetch for s.w.org to that list, but WordPress stopped emitting that hint in version 6.0 (Trac #40426), so on any site you are likely to be running there is nothing to remove. On a modern browser nothing is ever requested from s.w.org at all, because the polyfill that would fetch the images never loads.
The support test used to be the interesting part. It draws emoji to a canvas and reads the pixels back, and before WordPress 6.3 it did that on the main thread on every page view, which is why it showed up as a roughly 100 ms long task in performance traces (Trac #58472). 6.3 fixed most of that: the result is now cached in sessionStorage under the key wpEmojiSettingsSupports, and on browsers with OffscreenCanvas the test runs in a Web Worker instead of blocking the page. One detail for the curious: the loader’s own comment says the cache lasts a week, but it compares a millisecond timestamp against 604,800, which is a week in seconds, so the result is actually reused for about ten minutes per tab before the test runs again. Either way, it is no longer the cost it once was.
So this is still worth doing, because it is free and it removes a script your site does not need, but do not expect it to move your page speed score on its own. If a guide promises a 22 KB saving or a lighter main thread, it was written for a WordPress that no longer exists.
Video Tutorial
Here’s my quick video guide to disabling emojis in WordPress.
Disable WordPress Emojis with Plugin
The quickest and easiest way to disable emojis in WordPress is to use the Disable Emojis plugin. This is as simple as installing the plugin and activating it and poof! emoji support is gone.
If you head to Plugins/Add new in your WordPress dashboard and search “Disable Emojis” you’ll quickly find the plugin. Just click Install then Activate and emoji support will be removed from WordPress.
Disable WordPress Emojis with Functions.php Code
The code below will disable emojis in WordPress and can be used in your theme’s function.php. This is the more developer friendly approach.
You can also use this snippet in the Code Snippets WordPress plugin which allows you to easily add code snippets to your WordPress site.
add_action( 'init', 'smartwp_disable_emojis' );
function smartwp_disable_emojis() {
// Front end and admin
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );
// oEmbed iframes load their own copies. Most snippets miss these two.
remove_action( 'embed_head', 'print_emoji_detection_script' );
remove_action( 'enqueue_embed_scripts', 'wp_enqueue_emoji_styles' );
// Feeds and outgoing email
remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
// Classic editor plugin
add_filter( 'tiny_mce_plugins', 'smartwp_disable_emojis_tinymce' );
}
function smartwp_disable_emojis_tinymce( $plugins ) {
return is_array( $plugins ) ? array_diff( $plugins, array( 'wpemoji' ) ) : array();
}Two lines in there are missing from almost every version of this snippet you will find elsewhere: the embed_head and enqueue_embed_scripts removals. WordPress registers emoji support separately for oEmbed iframes, so without those the script keeps loading whenever your posts are embedded.
You may also notice older snippets only remove print_emoji_styles from wp_print_styles, even though WordPress 6.4 moved emoji CSS to a newer wp_enqueue_emoji_styles function. Those snippets still work, and it is worth knowing why: core deliberately checks whether print_emoji_styles is still hooked and bails out early if you have removed it. The back-compat is intentional, so there is no need to chase the newer hook on the front end.
Two things you will find in other versions of this snippet are safe to leave out. A wp_resource_hints filter that strips the s.w.org prefetch has had nothing to strip since WordPress 6.0, and add_filter( 'emoji_svg_url', '__return_false' ) only rewrites a URL inside settings that are never printed once the detection script is gone.
How to Check That It Worked
Load any page on your site in a private window, view source, and search for emoji. If it worked you will find nothing. Before the change you would see an inline script block containing wpemojiSettings near the top of the head, and a <style id="wp-emoji-styles-inline-css"> block below it.
One thing that confuses people: open DevTools, then Application, then Session Storage, and you may still see a wpEmojiSettingsSupports entry. That is the cached result of the old test from before you disabled it. It lives in the tab’s session storage, not on your site, and it goes away when the tab closes. It is not evidence the snippet failed.
Use a private window or purge your cache first. A cached copy of the page will happily keep serving the old markup and make you think the snippet failed.
Frequently Asked Questions
Will emojis stop working in my posts?
No, and this is the most common worry about it. Emoji are ordinary Unicode characters, and every current browser and operating system renders them without help. What you are removing is a compatibility layer that swapped emoji for images on browsers too old to display them, which in practice means browsers almost nobody still uses. Type an emoji into a post after disabling this and it will look exactly the same.
Plugin or code snippet, which is better?
They do the same job, so it comes down to preference. A plugin is easier to reverse and survives a theme change, which matters if someone else maintains the site. The snippet avoids adding a whole plugin for what amounts to a dozen lines of code. If you already run a performance plugin such as WP Rocket, check its settings first, since disabling emoji is usually a checkbox there and you do not need either option.
Where should the snippet go?
Not in your parent theme’s functions.php, because a theme update will erase it. Use a child theme, a small custom plugin, or a snippets plugin such as Code Snippets. Our guide to adding code snippets to WordPress covers the trade-offs of each.
Does this help Core Web Vitals?
Marginally, and less than it used to. Before WordPress 6.3 the loader could hold the main thread for around 100 ms, so removing it gave Interaction to Next Paint a genuine nudge. Since 6.3 the test is cached and offloaded to a Worker, so what is left is a couple of kilobytes of inline script. It will not change your Largest Contentful Paint, because that is almost always an image. Treat it as tidying rather than a fix: if your scores are poor, images and render-blocking CSS are where the actual problem is.
What is wpEmojiSettingsSupports?
The key WordPress uses in the browser’s session storage to remember the result of its emoji support test, added in 6.3 so the test does not have to run on every page. You will see it in DevTools under Application, then Session Storage. It is harmless, it belongs to the browser tab rather than your site, and it disappears when the tab is closed. If you have disabled emoji support it simply stops being written.
Is the emoji script a GDPR problem?
It was, a little, and now barely is. Until WordPress 6.0 every page told the browser to look up s.w.org, a WordPress.org domain, whether or not anything was needed from it, and that automatic connection is what the “GDPR friendly” label on the Disable Emojis plugin refers to. Core removed that hint in 6.0, and on a modern browser the polyfill never runs, so no request to s.w.org is made at all. Disabling the script removes even the theoretical case, which is a reasonable thing to want; it is just no longer the automatic third-party request it once was.
Just like that you’ve disabled emojis on your WordPress site. While this is only one small part of improving your site’s performance I highly recommend doing it. Be sure to check out more of our tips to speed up WordPress.
6 Responses
Thanks, i really needed that. I used the snippet as a extra Plugin is a bit too much in my eyes.
Does this disable them in form submissions?
Hello Andy,
that was exactly the code snippet I was looking for.
Thank you very much for publishing!
Kind regards,
Boris
doesn’t work for me
If you have Yoast installed it has a setting to disable the emoji script.
doesn't work for me