Why Word Renders Specific Unicode Glyphs Differently Per User on Co-author

When two or more users co-author a Word document, one user may see a specific Unicode glyph such as a checkmark, arrow, or emoji rendered correctly while another user sees a blank square, a different symbol, or a line break. This problem typically occurs because each co-author’s system uses a different font fallback chain or lacks the exact font that contains the glyph. Word does not embed every font used for Unicode glyphs into the document during co-authoring sessions, so the rendering depends entirely on what is installed locally. This article explains why font fallback behavior differs per user, how Word selects fallback fonts for Unicode characters, and what steps you can take to ensure consistent glyph rendering for all collaborators.

How Word Selects a Font for a Unicode Glyph

Word does not store a bitmap or vector image of every glyph in the document file. Instead, it stores the Unicode code point and the font name that was applied when the character was inserted. When a co-author opens the document, Word attempts to render the glyph using the specified font. If that font is not installed on the co-author’s system, Word falls back to a font that can display the glyph. The fallback mechanism follows a strict order:

The Font Fallback Chain in Windows

Windows maintains a list of fallback fonts in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink. For each base font, there is a comma-separated list of fallback fonts. For example, the fallback for Arial might include Segoe UI Symbol, Microsoft Sans Serif, and Noto Sans if installed. Word reads this chain at render time. If a co-author has a different Windows edition or has installed additional language packs, the fallback chain may differ, causing the same glyph to map to a different font.

Font Embedding Behavior During Co-authoring

When a document is saved locally or shared via email, Word can embed fonts using File > Options > Save > Embed fonts in the file. However, during real-time co-authoring in Microsoft 365, font embedding is limited. Word embeds only the fonts used in the document body if the file is saved to OneDrive or SharePoint, but it does not embed every system font that might be referenced by a Unicode fallback. As a result, a co-author who opens the document in the browser or on a device without the original font will see a different glyph.

Emoji Versus Symbol Glyph Rendering

Unicode glyphs fall into two categories that Word handles differently. Emoji characters such as U+1F600 (grinning face) are rendered by the Segoe UI Emoji font on Windows. If that font is missing or disabled, Word falls back to Segoe UI Symbol or a system emoji font from a language pack. Symbol glyphs such as U+2713 (check mark) or U+2192 (rightwards arrow) are typically rendered by Segoe UI Symbol or Microsoft Sans Serif. A co-author who has installed a third-party emoji font or has uninstalled Segoe UI Symbol will see a blank square or a different character.

Steps to Diagnose and Fix Glyph Rendering Differences

Check Which Font the Glyph Uses in the Original Document

1. Select the glyph in the original document
   Click on the character that renders correctly on your system. Look at the font name displayed in the Home tab of the ribbon, in the Font group.
2. Identify the Unicode code point
   Press Alt+X immediately after selecting the glyph. Word converts the character to its hexadecimal Unicode code point. Write down the code point, for example 2713 for a check mark.
3. Ask the co-author to select the same glyph
   Have the co-author open the document and select the same character. Note the font name that appears in the Font group on their system. If it differs from yours, the fallback chain is substituting a different font.

Install the Missing Font on the Co-author’s System

1. Obtain the original font file
   Download the font from a trusted source such as the font vendor’s website or extract it from a system that has it installed. Common fallback fonts like Segoe UI Symbol are part of Windows and can be reinstalled via Windows Features.
2. Install the font
   Right-click the font file and select Install. Restart Word and reopen the document.
3. Verify the glyph renders correctly
   Select the glyph again and confirm the font name now matches the original font.

Embed Fonts in the Document Before Sharing

1. Open the document that contains the glyphs
   Make sure you are the owner and have full edit permissions.
2. Go to File > Options > Save
   Scroll to the Preserve fidelity when sharing this document section.
3. Check Embed fonts in the file
   Select Embed only the characters used in the document to keep file size smaller, or select Embed all characters for full fidelity. Click OK.
4. Save and re-upload the document
   Save the file locally, then upload it to OneDrive or SharePoint. Co-authors who open the document will see the embedded fonts.

Use a Common Font That Supports the Glyph Across Systems

1. Select all text that uses the problematic glyph
   Press Ctrl+A to select the entire document, or select the specific paragraphs.
2. Apply a font that is installed on all co-author systems
   Choose a font such as Calibri, Arial, or Times New Roman. These fonts include basic Unicode symbols and are present on every Windows installation.
3. Replace the glyph with a text-based alternative
   If the glyph is a symbol like a check mark, consider using the Wingdings font or a simple letter like an X in a colored box. Wingdings is installed on all Windows systems.

If the Glyph Still Renders Differently

Word Online Renders Glyphs Using Browser Fonts

When a co-author opens the document in Word for the web, the browser controls font rendering. Browsers use their own fallback chains and may substitute system fonts with web-safe fonts. For example, Chrome uses the Noto family for emoji if Segoe UI Emoji is not available. The same glyph may appear as a color emoji in the desktop app but as a black-and-white symbol in the browser.

Windows Language Packs Add or Remove Fallback Fonts

A co-author who has installed a language pack for Arabic, Chinese, or Japanese may have additional fallback fonts such as Microsoft YaHei or Nirmala UI. These fonts may contain glyphs that override the default fallback, causing a different rendering. Uninstalling the language pack or adjusting the font fallback registry can resolve the issue, but this is an advanced step that requires administrator rights.

Third-Party Font Managers Can Block System Fonts

If a co-author uses a font management tool such as Suitcase Fusion or FontBase, the tool may disable system fonts like Segoe UI Symbol during a session. The co-author should check the font manager’s active font list and ensure that the required fallback fonts are enabled before opening the document.

Font Fallback Chain Comparison: Windows 10 vs Windows 11

Item	Windows 10 (21H2)	Windows 11 (22H2)
Default emoji font	Segoe UI Emoji	Segoe UI Emoji (updated glyph set)
Default symbol font	Segoe UI Symbol	Segoe UI Symbol
Fallback for missing symbols	Microsoft Sans Serif	Microsoft Sans Serif then Segoe UI
FontLink registry location	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink	Same location
Language pack impact	Adds East Asian fallback fonts	Adds East Asian and Indic fallback fonts

Word renders Unicode glyphs differently per user during co-authoring because each system uses a unique font fallback chain determined by the Windows edition, installed language packs, and third-party font management tools. You can ensure consistent rendering by embedding fonts in the document, applying a universally installed font like Calibri, or replacing the glyph with a text-based alternative. For advanced control, check the FontLink registry on each co-author’s system to align the fallback order.