Han Unification merged characters that share the same origin into single code points. But what happens when you need to specify an exact glyph variant? Japanese names, historical documents, and calligraphic traditions demand precise glyph control beyond what a font's default rendering provides.

For example, the character 辻 (U+8FBB, “tsuji”, a common Japanese surname) has two accepted forms: one with one dot on the left radical (一点しんにょう) and one with two dots (二点しんにょう). Both are “correct” — but which one appears depends on the font, and there is no way to choose using the base code point alone.

Unicode's solution is Variation Sequences: a base character followed by a special variation selector character that specifies the exact glyph form.

Ideographic Variation Sequences (IVS) use variation selectors from the range U+E0100 through U+E01EF (240 selectors, called VS17 through VS256). An IVS is a two-character sequence:

Base character + Variation Selector = IVS

Example:
葛 (U+845B) + VS17 (U+E0100) = 葛󠄀 (specific variant)
葛 (U+845B) alone            = 葛  (default glyph)

The variation selector is invisible — it produces no glyph of its own. But a font that supports IVS will render a different glyph when it encounters the sequence.

In JavaScript, each variation selector in this range requires a surrogate pair (2 UTF-16 code units), so an IVS takes 3–4 code units total despite being one grapheme cluster.

Standardized Variation Sequences (SVS) use a different, smaller set of variation selectors: U+FE00 through U+FE0F (VS1 through VS16). These are used for:

The most widely known SVS usage is the text/emoji toggle. Many characters have both a text presentation (monochrome, simple) and an emoji presentation (colorful). VS15 forces text style, VS16 forces emoji style:

// Same base character, different presentations:
"\u2764"           // ❤ (default, usually emoji)
"\u2764\uFE0E"    // ❤︎ (text presentation, VS15)
"\u2764\uFE0F"    // ❤️ (emoji presentation, VS16)

// The selectors are invisible but change rendering:
"❤️".length  // 2 (base + VS16, both in BMP)

Unlike IVS selectors (which are in the SMP and need surrogates), SVS selectors are in the BMP (U+FE00–FE0F) and each take just one UTF-16 code unit.

Which variation selectors map to which glyphs is not arbitrary — it is recorded in the Ideographic Variation Database (IVD), maintained by the Unicode Consortium. The IVD contains named collections:

Adobe-Japan1 is the most widely supported collection. It maps IVS sequences to specific CID (Character ID) numbers in the Adobe-Japan1-7 character collection, which professional Japanese fonts implement. A font that supports Adobe-Japan1 IVS can render thousands of glyph variants.

Moji_Joho (文字情報) is maintained by Japan's Information-technology Promotion Agency (IPA) and focuses on character variants used in official government documents and the family register system (戸籍).

IVS only works if the font supports it. A font must contain:

• The glyph variants for each supported IVS sequence
• A cmap table (specifically format 14, Unicode Variation Sequences) that maps base+selector pairs to glyphs

Major fonts with IVS support include:

If a font does not support a particular IVS, it simply renders the base character's default glyph and ignores the variation selector. This is a graceful fallback — the text remains legible, just not in the specific variant requested.

The character 邉 (U+9089) holds the record for the most registered IVS sequences. It has approximately 47 variant forms in the Moji_Joho collection, reflecting the many ways this character has been written in Japanese family registers over the centuries.

The surname 渡邉 (Watanabe) is notorious in Japan for having dozens of variant spellings. Municipal offices maintaining family registers need to faithfully reproduce the exact variant used in each family's records, which is why the Moji_Joho collection registers so many forms.

This is a case where IVS is essential: without it, government systems could not accurately record the legally distinct name variants that Japanese law requires preserving.

// The 邉 character with different IVS:
"邉"                    // Default glyph
"邉\u{E0100}"          // Variant 1 (VS17)
"邉\u{E0101}"          // Variant 2 (VS18)
// ... up to ~47 registered variants

// Each is one grapheme cluster:
const seg = new Intl.Segmenter();
[...seg.segment("邉\u{E0100}")].length  // 1