Have you noticed that some Alt codes are not working? Have you ever typed an Alt code that works perfectly in Microsoft Word, only to get a completely wrong character (or a plain question mark) in Notepad or another application? And has this ever started happening in a program that used to work just fine? You are not imagining things, and your keyboard is not broken. There is a precise technical reason why Alt codes above 255 work in some programs and fail in others, and why some programs that once handled them correctly have stopped doing so in newer versions.
This article explains exactly what is happening, from the hardware origins of the IBM PC through the modern Windows application framework, with both a full technical explanation and a plain-English version that anyone can follow.
Quick Answer (TL;DR)
Alt codes above 255 fail in certain programs because those programs apply a modulo 256 operation to the number you type. This reduces the value to an 8-bit range (0–255), mapping it to a completely different character. Programs that do not apply this truncation pass the full number through as a Unicode code point, displaying the correct character.
The underlying reason is Windows’ two-tier text control architecture: the legacy Edit control enforces the 8-bit limit, while the RichEdit control implements its own 16-bit input handler that bypasses the limit entirely. Whether a program uses the Edit control, uses RichEdit with its custom handler active, or routes through the standard input pipeline determines whether extended Alt codes work.
What Are Alt Codes?
Alt codes are a Windows feature that lets you type characters not found on your keyboard by holding the Alt key and entering a number on the numeric keypad. When you release the Alt key, Windows looks up the number and inserts the corresponding character into the active text field. This mechanism was originally implemented at the BIOS firmware level (not by the keyboard hardware itself) and has been carried forward into every version of Windows since.
There are three distinct systems of Alt codes:
System 1: Alt Codes Without a Leading Zero (Alt + 1 to 255)
When you type a number from 1 to 255 without a leading zero, Windows looks up the character in the OEM code page (historically IBM PC Code Page 437, or CP437). This is the original Alt code system. Examples: Alt+3 gives ♥ (heart), Alt+14 gives ♫ (musical note), Alt+163 gives ú in CP437.
System 2: Alt Codes With a Leading Zero (Alt + 0 + number)
When you type a leading zero followed by a number (e.g., Alt+0163), Windows uses the Windows ANSI code page (typically CP1252 for Western languages). The same number can produce a different character depending on whether you include the leading zero. For example, Alt+163 gives ú (from CP437) while Alt+0163 gives £ (pound sterling, from CP1252).
System 3: Extended Alt Codes Above 255
Numbers above 255 extend beyond the 256-character limit of any code page. On applications that support it, the number is treated directly as a Unicode code point, giving access to the full Unicode standard of over 140,000 characters. The Thai baht symbol ฿ is Unicode code point 3647; the Greek capital PSI Ψ is code point 936; the snowman ☃ is code point 9731. This is where compatibility problems arise, because not all applications handle these values correctly.
A Brief Background: Character Encoding and the 256-Character Limit
The Old World: Code Pages and 8-Bit Characters
In the early days of personal computing, each character was stored as a single byte, specifically a number from 0 to 255. ASCII itself defined only 128 characters (codes 0–127): basic English letters, digits, punctuation, and control characters. The IBM PC extended this to 256 characters using Code Page 437 (CP437), adding graphical symbols, box-drawing characters, and accented letters. Other OEM variants such as CP850 (Western European) also existed.
Different regions used different code pages, creating fragmentation. The Windows code page CP1252 (often called “ANSI,” though that is technically a misnomer) became the standard for Western Windows systems. The same byte value could mean different characters depending on which code page was active.
The New World: Unicode
Unicode assigns a unique code point to every character in every language, totalling over 140,000 characters. Modern Windows is fundamentally Unicode-based. This is why Alt codes above 255 can theoretically work: if an application treats the Alt code number as a Unicode code point, any character in the Unicode standard is reachable without the 256-character ceiling.
However, support for entering Unicode characters via decimal Alt codes has been inconsistent across applications. Some handle it correctly; others apply the legacy 8-bit overflow behavior. This inconsistency is the central subject of this article.
How Alt Codes Work Internally: The Windows Message System
The BIOS Origin: The 8-Bit AL Register and Integer Overflow
The Alt-numpad input system was originally implemented in the IBM PC BIOS in the early 1980s. The BIOS accumulated the digits typed while Alt was held in an 8-bit register (the AL register in x86 assembly language). An 8-bit register holds exactly 256 values (0 through 255).
If you type a number larger than 255, an integer overflow occurs. Consider Alt+259: in binary, 259 is 100000011. The AL register can only store 8 bits, so the leading ‘1’ is silently discarded, leaving 00000011, which is the number 3. So Alt+259 produced the same character as Alt+3 (the heart symbol ♥). This is mathematically equivalent to 259 mod 256 = 3. This arithmetic consequence of the hardware was baked into the firmware and became the baseline behavior that later Windows versions preserved.
The Alt-Numpad Buffer in Modern Windows
Modern Windows preserves the Alt-numpad system for backward compatibility. When you hold Alt and press numpad keys, the TranslateMessage function (part of the Windows input processing pipeline) intercepts the input and accumulates the digits into a buffer. When you release Alt, Windows converts the accumulated number to a character and sends a WM_CHAR message to the active application.
The critical variable is whether the application receives the full accumulated number, or whether the OS-level buffer has already applied modulo 256 before the WM_CHAR message is sent. This depends entirely on which text input component the application uses.
The Core Technical Split: Edit Control vs. RichEdit Control
This is the most important section for understanding the compatibility differences. Windows provides two fundamentally different text-entry components, and which one an application uses largely determines whether extended Alt codes work.
The Standard Edit Control
The Edit control (sometimes referred to as edit.dll) is the basic text box Windows has provided since its earliest versions. It appears in simple dialogs, search fields, address bars, and historically in applications like classic Notepad.
The Edit control relies on the standard TranslateMessage function, which uses the legacy 8-bit accumulation buffer. Any Alt code above 255 has modulo 256 applied before the application’s own code runs. The application never sees the value 3647 or 936; it receives 63 or 168 respectively, and displays the corresponding code-page character.
The RichEdit Control
The RichEdit control is a more powerful text engine used in applications such as WordPad, Microsoft Word, PowerPoint, and OneNote. To support Unicode and rich formatting, RichEdit implements its own keyboard input handler.
Instead of relying on TranslateMessage to accumulate Alt code digits, RichEdit applications monitor WM_SYSKEYDOWN messages directly and maintain their own 16-bit buffer. A 16-bit buffer holds values from 0 to 65,535, well above the 8-bit limit of the legacy system. Because the input never passes through the OS-level 8-bit accumulator, the full decimal value is received as a Unicode code point. No modulo 256 is applied.
This is the mechanism by which Word, WordPad, PowerPoint, OneNote, and desktop Outlook correctly display Ψ for Alt+936 and ฿ for Alt+3647.
🧩 Edit vs. RichEdit: The Core Distinction
Edit control: uses TranslateMessage (OS-level 8-bit buffer) → modulo 256 applies → wrong character for Alt codes above 255.
RichEdit control with custom handler: monitors WM_SYSKEYDOWN directly, maintains 16-bit buffer → no modulo 256 → correct Unicode character.
This distinction drives nearly every row in the compatibility table.
Plain English Explanation: Two Analogies
The Librarian Analogy
Imagine the computer’s characters as books in a massive library. The keys on your keyboard are the books on the front shelf. An Alt code is a call number for a book deep in the stacks. When you hold Alt and type 3647, you are telling the librarian to find book number 3647.
The problem is that some librarians were trained to count only up to 255. If you ask for book 3647, a librarian who can only process numbers in the 0–255 range will perform a mathematical shortcut (modulo) and bring out a completely different book. That is precisely why the Thai baht symbol becomes a question mark: the call number is truncated before reaching the right shelf.
The Odometer Analogy
Imagine a classic car odometer with only three digits. Once it hits 999, it rolls back to 000, always showing only the last three digits of the total mileage. An 8-bit input system works the same way: if you type Alt+3647, only the portion that fits within 0–255 is remembered. The rest is discarded. Programs with 16-bit RichEdit buffers read the entire number and find the correct character.
💡 The Simplest Summary
Some programs have a decoder that only understands numbers up to 255. Type a bigger number and the decoder gets confused, giving you the wrong symbol. Programs like Word have a smarter decoder that understands much bigger numbers. That is why the same Alt code gives different results in different programs.
Why the Windows 11 Notepad Is a Special Case
The Windows 11 Notepad situation is especially interesting because it involves both control types across its history.
Old Notepad (Windows 10 and earlier): For nearly thirty years, Notepad was built on the standard Edit control (edit.dll). By rights, this should have enforced modulo 256. However, Microsoft made incremental tweaks over the years, particularly in later Windows 10 builds, that allowed the Edit control to pass higher Unicode values through in Notepad. This gave users genuine, if undocumented, support for extended Alt codes: Alt+3647 correctly produced ฿ and Alt+936 correctly produced Ψ. Users came to rely on this. Note: some secondary sources incorrectly state that classic or old Notepad always applied modulo 256 to Alt codes above 255 and wrapped them. Direct testing contradicts this: Windows 10 Notepad correctly passed extended Alt codes through as a result of Microsoft’s accumulated Unicode improvements to the Edit control.
New Notepad (Windows 11): Microsoft rebuilt Notepad from the ground up using the WinUI 3 framework with a RichEdit-based text engine. Counterintuitively, this broke extended Alt code support rather than improving it. While RichEdit technically supports high-value Alt codes when its custom handler is active, the new Notepad’s implementation prioritized plain-text behavior and tight WinUI 3 input pipeline integration. The message-handling loop was wired back to the standard system input pathway, reverting to modulo 256 behavior. The undocumented Unicode support of older Notepad was lost.
Beyond the modulo 256 issue, some users have reported additional bugs in Windows 11 Notepad where Alt code input may only function correctly on the first use per editing session, with subsequent attempts producing inconsistent results. Microsoft has acknowledged these issues. As a partial compensation, Microsoft added Alt+X support to Windows 11 Notepad (see the Workarounds section).
The Modulo 256 Problem: Three Worked Examples
What Is Modulo?
Modulo is a mathematical operation that returns the remainder of a division. 10 mod 3 = 1 (because 10 ÷ 3 = 3 remainder 1). When a program applies modulo 256 to an Alt code, it discards all higher-order bits and collapses the value into the 0–255 range.
Example 1: Alt+936 (Ψ vs. ¿)
You expect: Alt+936 = Ψ (Greek Capital Letter PSI, Unicode U+03A8 = decimal 936)
What broken programs show: 936 ÷ 256 = 3 remainder 168. Code 168 in CP437 = ¿ (inverted question mark)
936 mod 256 = 168 → ¿
Example 2: Alt+3647 (฿ vs. ?)
You expect: Alt+3647 = ฿ (Thai Baht, Unicode U+0E3F = decimal 3647)
What broken programs show: 3647 ÷ 256 = 14 remainder 63. Code 63 = ? (question mark, ASCII 63)
3647 mod 256 = 63 → ?
Example 3: Alt+9731 (☃ vs. ♥)
You expect: Alt+9731 = ☃ (Snowman, Unicode U+2603 = decimal 9731)
What broken programs show: 9731 ÷ 256 = 38 remainder 3. Code 3 in CP437 = ♥ (heart symbol, the same as Alt+3)
9731 mod 256 = 3 → ♥
ℹ️ It Is Modulo 256, Not 255
256 is the total count of values in one byte (0 through 255). Applying mod 256 keeps only the lowest 8 bits. All three examples confirm this: 936 mod 256 = 168 (¿), 3647 mod 256 = 63 (?), 9731 mod 256 = 3 (♥).
The Formula
Displayed character = code page character for (Alt code number mod 256)
Additional quick-reference calculations:
- Alt+257: 257 mod 256 = 1. Code 1 in CP437 = ☺ (smiley face). Same as Alt+1.
- Alt+512: 512 mod 256 = 0. Code 0 = null character. Displays as nothing.
- Alt+1000: 1000 mod 256 = 232. Code 232 in CP437 = Φ (Greek capital Phi).
Why Different Applications Behave Differently
Word, WordPad, PowerPoint, OneNote: RichEdit Custom Handler Active
Microsoft Word uses a deep implementation of the RichEdit control with its 16-bit custom input handler fully active. It monitors WM_SYSKEYDOWN messages directly, accumulates Alt code digits in its own buffer without passing them through the OS-level TranslateMessage accumulator, and treats the result as a Unicode code point. WordPad, PowerPoint, and OneNote use the same mechanism and have the same result: extended Alt codes work correctly.
Excel: Specialized Grid Control, Not RichEdit
Excel is perhaps the most surprising entry in the compatibility table because it is part of the same Office suite as Word. The difference is that Excel’s cell input component is not a standard RichEdit control. It is a specialized grid editing control tightly integrated with Excel’s cell value and formula model. This control routes input through the standard system pathway, applying modulo 256. Extended Alt codes therefore fail in Excel cells even though they work perfectly in Word.
Classic Outlook Desktop: RichEdit Handler Active
The desktop versions of Outlook (Office 2021 and Microsoft 365) use a message composition engine built on the same RichEdit foundation as Word. Extended Alt codes work correctly in the Outlook compose window, for the same reason they work in Word: the RichEdit 16-bit custom handler is active. Note: some secondary sources incorrectly state that desktop Outlook applies modulo 256 to Alt codes above 255, equating it with Excel or Notepad. This confuses classic desktop Outlook with the Store-based Outlook Mail app and Outlook Web. The three behave completely differently. Direct testing of Outlook in Office 2021 and Microsoft 365 confirms that extended Alt codes work correctly in the compose window.
Modern Outlook (Store/Web), New Notepad: Standard Input Pathway
The Outlook Mail app from the Microsoft Store, Outlook on the Web, and Windows 11 Notepad all share a common characteristic: their text input is handled through modern frameworks (UWP, WinUI 3, or browser/Chromium engines) that route keyboard input through the standard Windows message pathway rather than a custom RichEdit handler. Modulo 256 is applied at the OS input level before the application sees the character. Extended Alt codes fail in all of these.
Notepad++ (Scintilla Engine): A Unique Case
Notepad++ does not use the Windows Edit control or the Microsoft RichEdit control. It is built on the Scintilla text editing component, which implements its own complete input handling system. Scintilla handles Alt code input differently from both the standard Edit control and the RichEdit control.
Direct testing of Notepad++ v8.9.2 shows the following behaviour:
- Alt codes 1–255: ✔ Work correctly. Scintilla processes these through its own input pathway and produces the expected OEM code-page character.
- Alt codes 256 and above: ✘ Do not work correctly. Values above 255 are subject to modulo 256 truncation within Scintilla’s input system, so the character at the remainder position is produced instead of the intended Unicode character.
This places Notepad++ in the same practical category as applications using the standard Edit control for extended Alt codes: the modulo 256 limit applies, and high-value Unicode characters cannot be entered via the decimal Alt-numpad method. Unlike the Edit control, however, this behaviour originates inside Scintilla’s own input handler rather than in the OS-level TranslateMessage function.
UltraEdit: Custom Unicode Text Engine
UltraEdit 2024 implements its own custom text engine that correctly processes extended Alt codes as Unicode code points, independent of either the Edit control or the RichEdit pathway. Both Alt codes 1–255 and extended codes above 255 work correctly. Note: some secondary sources incorrectly group UltraEdit with Notepad++ and claim that UltraEdit applies modulo 256 to codes above 255. This is wrong. UltraEdit and Notepad++ have entirely different text engines and behave completely differently. Direct testing of UltraEdit 2024 confirms that extended Alt codes work correctly as full Unicode code points.
Application Compatibility Table
The table below documents which applications support Alt codes above 255 and explains the underlying mechanism responsible for each application’s behavior.
| Application / Program | Alt 1–255 | Alt 256+ | Control Type / Reason |
|---|---|---|---|
| Notepad (Windows 10 and older) | ✔ YES | ✔ YES | Edit control + Microsoft Unicode tweaks (accidental support) |
| Notepad (Windows 11) | ✔ YES | ✘ NO | WinUI 3 RichEdit, reverted to system input pathway |
| WordPad (discontinued) | ✔ YES | ✔ YES | RichEdit (16-bit custom handler) |
| Word (Office 2021 & 365) | ✔ YES | ✔ YES | RichEdit (16-bit custom handler) |
| Outlook Desktop (Office 2021 & 365) | ✔ YES | ✔ YES | RichEdit (16-bit custom handler) |
| Outlook (Mail / Microsoft Store) | ✔ YES | ✘ NO | UWP framework, standard system input pathway |
| Outlook (Web) | ✔ YES | ✘ NO | Browser/Chromium engine |
| Excel (Office 2021 & 365) | ✔ YES | ✘ NO | Custom grid control, standard system input pathway |
| PowerPoint (Office 2021 & 365) | ✔ YES | ✔ YES | RichEdit (16-bit custom handler) |
| OneNote (Office 2021 & 365) | ✔ YES | ✔ YES | RichEdit (16-bit custom handler) |
| Publisher (Office 2021 & 365) | ✔ YES | ✘ NO | Legacy layout control, standard system input pathway |
| UltraEdit 2024 | ✔ YES | ✔ YES | Custom Unicode text engine |
| Notepad++ v8.9.2 | ✔ YES | ✘ NO | Scintilla engine (modulo 256 for values above 255) |
✔ YES = Alt codes above 255 work as correct Unicode code points. ✘ NO = modulo 256 is applied, or the standard Alt-numpad method does not function.
Workarounds: How to Type Special Characters When Extended Alt Codes Fail
1. Copy and Paste from a Compatible Application
The simplest solution is to type the character in Microsoft Word or WordPad, then copy and paste it. Unicode text is universally supported in modern Windows applications. It is only the Alt-code entry method that is constrained; once the character exists as Unicode text, any Unicode-capable application can receive it via paste.
2. Use Alt+X in Microsoft Word or Desktop Outlook
In Word and desktop Outlook, type the hexadecimal Unicode code point of the character followed immediately by Alt+X. Word converts it to the character:
| Character | Type this hex code | Then press | Result |
|---|---|---|---|
| Thai Baht (฿) | 0E3F | Alt + X | ฿ |
| Greek PSI (Ψ) | 03A8 | Alt + X | Ψ |
| Euro (€) | 20AC | Alt + X | € |
| Snowman (☃) | 2603 | Alt + X | ☃ |
Alt+X also works in reverse: place your cursor immediately after any character and press Alt+X to reveal its hexadecimal Unicode code point. This is useful for identifying unknown symbols.
3. Use Alt+X in Windows 11 Notepad
Microsoft added Alt+X support to Windows 11 Notepad as a compensating feature for the loss of extended decimal Alt code support. While decimal Alt codes above 255 do not work correctly in Windows 11 Notepad due to the modulo 256 regression, you can use the hex-code + Alt+X method instead. Type 0E3F then press Alt+X to insert the Thai baht symbol ฿, for example.
4. Enable the Hexadecimal Numpad (Registry Fix)
Windows contains a hidden feature to enable hexadecimal Unicode entry via the numeric keypad system-wide:
- Press Win+R, type
regedit, press Enter. - Navigate to
HKEY_CURRENT_USER\Control Panel\Input Method. - Create a new String Value (REG_SZ) named
EnableHexNumpad. - Set its value to
1. - Restart the computer.
After restarting, hold Alt, press the + key on the numeric keypad, type the hexadecimal code, then release Alt. For example, Alt + [+] + E3F inserts ฿. Note that this method may not work in all applications, particularly browser-based ones.
5. Use the Windows Character Map (charmap.exe)
Press Win + R, type charmap, press Enter. Browse the full Unicode character set, select a character, click Copy, and paste into your application.
6. Use the Windows Emoji and Symbol Picker
Press Win + . (period) or Win + ; (semicolon) to open the built-in symbol picker. The Symbols section includes currency, math, and Latin extended characters. This is Microsoft’s recommended modern solution for Unicode character insertion.
7. Insert Symbol Dialog in Office Applications
In Word, Excel, PowerPoint, and other Office applications: Insert → Symbol → More Symbols. Browse any Unicode character, insert it, and see its keyboard shortcut.
8. Check Num Lock, Keyboard Layout, and Third-Party Software
Before assuming a software problem, confirm that Num Lock is enabled. Alt codes require the numeric keypad, not the top-row number keys. On laptops, check whether Fn+Alt is required instead of Alt alone.
Also check for third-party keyboard managers, Input Method Editors (IMEs), or accessibility tools that may intercept Alt key input before it reaches the application. Temporarily disabling such tools can confirm whether they are the cause.
If you recently enabled the “Beta: Use Unicode UTF-8” system locale option (Region → Administrative → Change system locale), this changes how Windows handles OEM and ANSI code pages and can affect the characters produced by Alt codes 1–255, not just extended codes.
A Note on Fonts: When the Character Is Correct But Shows as a Box
Even when an application correctly inserts a Unicode character from an extended Alt code, it may not display correctly if the active font does not include a glyph for that code point. The operating system typically shows a small empty box, a placeholder rectangle, or a question mark in a box, sometimes called a “tofu” character.
This is a different problem from the modulo 256 issue: the character has been correctly inserted, but the font simply lacks a visual representation for it. To resolve this, switch to a font with broad Unicode coverage such as Arial Unicode MS, Segoe UI Symbol, Segoe UI, or any of the Noto font family. The Windows Character Map utility can help identify which fonts contain a given character.
Cross-Platform Note: Alt Codes Are Windows-Specific
Alt codes are a Windows-only feature rooted in IBM PC BIOS history. Other operating systems use different methods:
- macOS: Uses the Option key with letter combinations (e.g., Option+G for ©). For arbitrary Unicode, use the Character Viewer (Control+Command+Space) or enable Unicode Hex Input in System Settings → Keyboard, then hold Option and type the hex code.
- Linux: Most desktop environments support Ctrl+Shift+U followed by a Unicode hex code and Enter (e.g., Ctrl+Shift+U, then 0e3f, Enter for ฿) in GTK and Qt applications.
- ChromeOS: Similar to Linux; the Windows Alt-numpad method does not apply. Use ChromeOS input methods or the on-screen keyboard.
Frequently Asked Questions
Q: Does the modulo 256 issue affect Alt codes 1–255?
No. Alt codes from 1 to 255 are fully contained within a single byte, and modulo 256 of any number below 256 returns the same number. Alt codes 1–255 work consistently in virtually all Windows applications that support Alt codes at all, including Windows 11 Notepad.
Q: Why do Alt codes above 255 not work in Notepad++?
Notepad++ uses the Scintilla text editing component, which implements its own complete input handling system. Alt codes 1–255 work correctly in Notepad++. However, for values above 255, Scintilla’s input handler applies modulo 256 truncation, meaning the character at the remainder position is produced instead of the intended Unicode code point. This is the same practical outcome as applications using the standard Windows Edit control, though the truncation happens inside Scintilla rather than in the OS-level TranslateMessage function.
Q: Is the Windows 11 Notepad regression a bug or an intentional change?
From a user perspective, it is a regression. From a developer perspective, the modern WinUI 3 input pipeline standardizes input handling across all WinUI 3 components, and the previous extended Alt code behavior in Windows 10 Notepad was an undocumented side effect of incremental tweaks rather than a supported feature. Restoring the custom Alt-code handler in the new Notepad would require specific engineering work. Microsoft partially compensated by adding Alt+X support to Windows 11 Notepad.
Q: What is the difference between Alt+936 (no leading zero) and Alt+0936 (leading zero)?
The leading zero determines which code page is used for the modulo-256 result. Without a leading zero, Windows uses the OEM code page (CP437); with a leading zero, it uses the ANSI code page (CP1252). For values above 255, modulo 256 is applied first in both cases, and the resulting remainder is then looked up in the respective code page. In RichEdit applications that do not apply modulo 256, both Alt+936 and Alt+0936 pass 936 as a Unicode code point and produce Ψ, making the leading-zero distinction irrelevant for extended codes.
Q: Do Alt codes work on laptops without a numeric keypad?
Most laptops have a hidden numeric keypad accessible via the Fn key. Whether this works identically for Alt codes depends on the laptop model. Using an external USB numeric keypad is the most reliable option. The on-screen keyboard also includes a visible numeric keypad (search for “On-Screen Keyboard” in the Start menu).
Conclusion
Alt codes above 255 do not work in some programs because of a fundamental split in Windows’ text input architecture. The legacy Edit control routes Alt code input through the standard Windows TranslateMessage function, which uses an 8-bit buffer inherited from the original IBM PC BIOS, applying modulo 256 to any value above 255. The RichEdit control bypasses this by monitoring keyboard messages directly and maintaining a 16-bit buffer, allowing full Unicode code point values to pass through without truncation.
Applications built on RichEdit with its custom handler active (Word, WordPad, PowerPoint, OneNote, and desktop Outlook) correctly display the intended Unicode character for extended Alt codes. Applications that route input through the standard system pathway (Excel, Publisher, Windows 11 Notepad, Store Outlook, and web-based applications) apply modulo 256 and produce the wrong character.
The Windows 11 Notepad case is a particularly instructive example: the application was rebuilt on WinUI 3 with a RichEdit engine, yet lost the extended Alt code support of its predecessor, because its message-handling loop reverts to the standard system input pathway. The undocumented Unicode support of Windows 10 Notepad, built up through years of incremental Microsoft tweaks to the Edit control, was not carried forward. Microsoft added Alt+X support to Windows 11 Notepad as a partial replacement.
For anyone who needs to type Unicode characters above code point 255, the most reliable methods are: decimal Alt codes in Word; hexadecimal code + Alt+X in Word, desktop Outlook, or Windows 11 Notepad; the Windows Emoji and Symbol Picker (Win+.); or the Windows Character Map (charmap.exe). The Unicode characters themselves paste correctly into any Unicode-capable application once inserted; it is only the Alt-code entry method that varies by application.
Appendix: Quick Reference for Alt Code Systems
| Method | Example | Code Page Used | Range |
|---|---|---|---|
| Alt + 1–255 (no leading zero) | Alt+65 = A | OEM (CP437) | 1–255 |
| Alt + 0 + 1–255 (leading zero) | Alt+0169 = © | ANSI (CP1252) | 0–255 |
| Alt + 256+ in RichEdit apps | Alt+936 = Ψ | Unicode code point | 256–65,535+ |
| Alt + 256+ in Edit/system-pathway apps | Alt+936 → 168 → ¿ | Code page + mod 256 | Effective: 0–255 |
| Hex code + Alt+X (Word, Win11 Notepad) | 03A8 then Alt+X = Ψ | Unicode (hexadecimal) | Any code point |
| Alt + [+] + hex (EnableHexNumpad reg.) | Alt++0E3F = ฿ | Unicode (hexadecimal) | Any code point |
References
- Alt code | Wikipedia
https://en.wikipedia.org/wiki/Alt_code
Comprehensive overview of Alt code history, code page behavior, RichEdit support, and the modulo 256 wrap-around rule. - Code Page 437 | Wikipedia
https://en.wikipedia.org/wiki/Code_page_437
Reference for the original IBM PC OEM character set used by Alt codes without a leading zero. - Windows-1252 | Wikipedia
https://en.wikipedia.org/wiki/Windows-1252
Reference for the Windows ANSI code page (CP1252) used by Alt codes with a leading zero. - The history of Alt+number sequences, and why Alt+9731 sometimes gives you a heart and sometimes a snowman | The Old New Thing (Microsoft Developer Blogs)
https://devblogs.microsoft.com/oldnewthing/20240702-00/?p=109951
Authoritative explanation of the 8-bit AL register origin, the modulo 256 behavior, and how RichEdit bypasses it with a custom handler. Primary technical source for this article. - Windows 11 Notepad | Math in Office (Microsoft Developer Blogs)
https://devblogs.microsoft.com/math-in-office/windows-11-notepad/
Microsoft’s own documentation of the Notepad rebuild on WinUI 3 / RichEdit, and the resulting changes to text input behavior. - About Rich Edit Controls | Win32 apps | Microsoft Learn
https://learn.microsoft.com/en-us/windows/win32/controls/about-rich-edit-controls
Official Microsoft documentation for the RichEdit control, including its Unicode input capabilities and architecture. - RichEditBox | Windows apps | Microsoft Learn
https://learn.microsoft.com/en-us/windows/apps/develop/ui/controls/rich-edit-box
Documentation for the WinUI 3 RichEditBox control used in the new Windows 11 Notepad. - WM_CHAR message (Winuser.h) | Win32 apps | Microsoft Learn
https://learn.microsoft.com/en-us/windows/win32/inputdev/wm-char
Official reference for the WM_CHAR Windows message, which carries the final character value to an application after Alt code input. - Using Keyboard Input | Win32 apps | Microsoft Learn
https://learn.microsoft.com/en-us/windows/win32/inputdev/using-keyboard-input
Microsoft documentation on WM_KEYDOWN, WM_SYSKEYDOWN, TranslateMessage, and the Windows keyboard input pipeline. - Insert ASCII or Unicode Latin-based symbols and characters | Microsoft Support
https://support.microsoft.com/en-us/office/insert-ascii-or-unicode-latin-based-symbols-and-characters-d13f58d3-7bcb-44a7-a4d5-972ee12e50e0
Official Microsoft guidance on Alt codes, the 256-character limit of extended ASCII, and the Alt+X method for Unicode input in Office. - Alt codes not working on Notepad | Microsoft Q&A
https://learn.microsoft.com/en-us/answers/questions/4280683/alt-codes-not-working-on-notepad
Microsoft Q&A thread where Microsoft acknowledged the UWP/WinUI Notepad has issues with Alt codes and recommended the classic Notepad as a workaround. - Alt codes are different in the new Windows | Microsoft Learn (Answers)
https://learn.microsoft.com/en-au/answers/questions/1851674/alt-codes-are-different-in-the-new-windows
User reports and responses confirming changed Alt code behavior in Windows 11 Notepad. - ALT and Unicode decimal combination input error | Microsoft Q&A
https://learn.microsoft.com/en-us/answers/questions/618120/alt-and-unicode-decimal-combination-input-error
Community thread documenting Unicode decimal input errors via Alt codes in modern Windows applications. - Alt code for the Thai Baht (฿) symbol | Microsoft Q&A
https://learn.microsoft.com/en-us/answers/questions/4366577/alt-code-for-the-thai-baht-symbol
User question and responses specifically addressing Alt+3647 behavior across applications. - Windows 10: Alt code results in wrong character | Super User
https://superuser.com/questions/1024948/windows-10-alt-code-results-in-wrong-character
Community explanation of the modulo 256 wrap-around, confirming that codes bigger than 256 get wrapped around. - Why are my Alt codes different from what is generally reported online? | Super User
https://superuser.com/questions/1451575/why-are-my-alt-codes-different-from-what-is-generally-reported-online
Detailed community answer explaining that Alt codes are generally limited to 256 characters with modulo 256 applied to larger values. - Cannot use Alt code for Unicode character insertion any more | Super User
https://superuser.com/questions/509330/cannot-use-alt-code-for-unicode-character-insertion-any-more
Community thread on loss of extended Alt code support across different Windows versions and applications. - IBM PC Alt + numpad for entering character codes: firmware, BIOS or OS? | Retrocomputing Stack Exchange
https://retrocomputing.stackexchange.com/questions/25016/ibm-pc-alt-numpad-for-entering-character-codes-firmware-bios-or-os
Technical discussion confirming the Alt-numpad mechanism was implemented at the BIOS firmware level, not in the keyboard hardware itself. - Alt Code in MS Word: different code but same character | Super User
https://superuser.com/questions/1561531/alt-code-in-ms-word-different-code-but-same-character
Community thread examining why certain Alt codes produce the same character in Word (relevant to RichEdit Unicode handling). - Insert symbols faster with the Alt+X trick in Word and Outlook | Office Watch
https://office-watch.com/2024/alt-x-trick-word-outlook/
Practical guide to the Alt+X hexadecimal shortcut in Word and Outlook, including the reverse-lookup feature. - HKEY_CURRENT_USER\Control Panel\Input Method (EnableHexNumpad) | Rene Nyffenegger’s Windows Registry Reference
https://www.renenyffenegger.ch/notes/Windows/registry/tree/HKEY_CURRENT_USER/Control-Panel/Input-Method/index
Technical reference for the EnableHexNumpad registry value that enables hexadecimal numpad Unicode input system-wide. - Scintilla Documentation | Scintilla.org
https://www.scintilla.org/ScintillaDoc.html
Official documentation for the Scintilla text editing component used by Notepad++, relevant to understanding Scintilla’s own input handling and why Alt codes above 255 do not work correctly in Notepad++. - Entering Alt Key Codes in a Document | Notepad++ Community Forum
https://community.notepad-plus-plus.org/topic/22066/entering-alt-key-codes-in-a-document
Notepad++ community discussion on Alt code input behaviour in Notepad++. - How to use Alt Codes without a Numpad on Windows 11/10 | The Windows Club
https://www.thewindowsclub.com/how-to-use-alt-codes-without-a-numpad-on-windows
Guidance for laptop users on using Alt codes without a dedicated numeric keypad. - How to Fix ALT Codes Not Working on Windows | MakeUseOf
https://www.makeuseof.com/alt-codes-not-working-windows/
Troubleshooting guide for Alt codes, including Num Lock, keyboard layout, IME, and third-party software interference. - Missing characters and glyphs | World Wide Web Consortium (W3C)
https://www.w3.org/International/articles/missing-char-glyph/index.en.html
W3C reference on why correctly encoded Unicode characters may not display if the active font lacks the glyph (the “tofu” problem).