Unicode Variation Selector-15 and some of my tears / benjamin wil

Unicode

Variation

Selector-15

and

some

of

my

tears

Unicode Variation Selector-15 and some of my tears

July 13, 2026

From my phone, I noticed that my website was displaying footnote backlink<br>glyphs as emoji in my RSS reader. It had not always been this way. I opened the<br>same page from a desktop browser and saw what I expected to see: a text-like<br>pictograph, in my article body’s font face. No emoji to be found. I checked<br>the HTML document source:

&#8617;

The RSS feed XML contained the same. So, that can be presented as either<br>text or an emoji? &x8617; is an HTML representation of the Unicode<br>codepoint U+21A9, Leftwards Arrow with<br>Hook. This led me to many relevant threads, pastes, and<br>blog posts1 in which others had observed similar issues with Leftwards Arrow with Hook and other, similar<br>navigation-decoration characters. We were all reacting to U+21A9 as rendered<br>without a Unicode standardized variation sequence specified. So<br>it’s up to whatever program is rendering U+21A9 to decide what to do. Which<br>version, the text or the emoji, should U+21A9 render.

I found the correct solution and some less correct solutions to this<br>issue. Before I describe them, I want to explore a slightly larger problem<br>introduced by variation selectors.

The downstream effects

For meta-ish content characters like backlink glyphs, the way forward is<br>clear for people who are technical: fix and/or configure the thing that<br>builds your web pages. Or complain in the direction of the people who can<br>fix and/or configure the thing.

For many of the other characters, it’s more complicated. Many of<br>these characters are used in body content to be expressive. Rendering<br>the text presentation instead of the emoji presentation, at worst,<br>could be a mistranslation. The technical standard<br>(see the emoji-data links, and specifically<br>emoji-data.txt) lists over 1,000 Unicode codepoints that<br>have both text and emoji presentations.

Codepoint<br>Glyph<br>As text<br>(+U+FE0E)<br>As emoji<br>(+U+FE0F)

U+00A9<br>©︎<br>©️

U+00AE<br>®︎<br>®️

U+2328<br>⌨︎<br>⌨️

U+25B6<br>▶︎<br>▶️

U+2603<br>☃︎<br>☃️

U+2620<br>☠︎<br>☠️

U+267B<br>♻︎<br>♻️

U+1F310<br>︎<br>️

U+1F312<br>︎<br>️

U+1F37C<br>︎<br>️

U+1F441<br>︎<br>️

U+1F509<br>︎<br>️

U+1F590<br>︎<br>️

U+1F635<br>︎<br>️

U+1F636<br>︎<br>️

Table 1 A small sampling of the 1,000+ Unicode codepoints<br>that have both text and emoji presentations. The Glyph column<br>may look different to you, depending on the application you're using to<br>read this article. I would hope the the +U+FE0E<br>and +U+FE0F columns do render the same<br>way for everyone.

There is no obvious, cut-and-dry user experience for writers here. Pictographs<br>and emoji are regular text as far as most programs are concerned, and<br>variation selectors remain invisible unless you go looking. Did the author<br>mean to present an umbrella ⛱︎ or an umbrella ⛱️<br>? We don’t know what their writing tool presented to them during editing. They<br>don’t know that we don’t see what they think we see when we’re reading<br>the thing. In a perfect world, all software knows about and inserts variation<br>selectors for the user. In reality, we know that software is bad.

I found documentation that indicates that the Unicode Technical Committee<br>is aware that variation selectors are complicated,2 and maybe weren’t the<br>best strategy.3 But what’s done is done and can’t be undone when it comes<br>to the Unicode Standard.

The most correct solution

You can specify, in your source document, which version you want rendered.<br>You do this by combining the variation selector codepoint with the preceding<br>codepoint you want to render. In my case, that’s U+FE0E, Variation Selector-15. Using my source document’s<br>backlink HTML markup as an example:

&#8617;&#xFE0E;

And, if I wanted, I could do the opposite: force the emoji presentation,<br>using U+FE0F, Variation Selector-16.

↩︎

Fig. 1<br>The pictogram via U+21A9 U+FE0E.

↩️

Fig. 2<br>The emoji via U+21A9 alone, next to the emoji rendered<br>via U+21A9 U+FE0F, where U-FE0F, Variation Selector-16 coerces the glyph to<br>use its full-colour emoji variant.

Fig. 3<br>Here's the image of the pictogram version and the iOS<br>emoji version as rendered via U+21A9 alone. As I've<br>already mentioned, which variant you see sans-selector can differ<br>per application.

So, I can fix this issue for myself. I’m fortunate that I build the software<br>that generates this website; and I’m fortunate that the library I<br>use to generate HTML from my Markdown source documents (Kramdown)<br>has a configurable footnote backlink glyph. There are authors using the<br>Mistune library (for example, via the Bear blogging platform),4<br>or perhaps some other niche content rendering library, that don’t have the<br>same luxury as of this writing.

Some less reliable solutions

If you’re in a position where you don’t control the software that builds<br>HTML from your source documents, and, for some reason, it’s not possible to<br>insert a variation selector character where you want it, there are some other<br>things you can try. (At least...