Skip to content

Alt Code

Enter a character in Microsoft PC environments by holding Alt, typing a decimal number on the numeric keypad, and interpreting that number under a context-dependent legacy or Unicode mapping.

Version
v1 · 2026-08-30 · History
Domain-specific #
1272
Origin domain
computer input
Subdomain
microsoft pc keyboard input
Aliases
Alt numpad input method, Alt numeric input, Alt-code entry

Core Idea

An Alt Code is a character-entry method inherited from IBM-compatible personal computers and retained in Microsoft environments. A user holds the Alt modifier, types a decimal sequence on the numeric keypad, and releases Alt; the input system or receiving control interprets the accumulated number under a particular mapping and emits a character or control value.[1][2] The name is often used for a table entry such as “Alt+0169,” but the abstraction is the input protocol, not the table.

The locked identity is input focus + held Alt state + numeric-keypad digit sequence + completion on Alt release + selected interpretation rule + numeric value lookup or truncation + emitted character. The interpretation rule is indispensable. The same digits need not identify the same character across an OEM code page, an input-locale “ANSI” code page, or a control that treats values above 255 as Unicode. Raymond Chen’s account of Windows compatibility explains why a no-leading-zero sequence normally selects the OEM path, while a leading-zero sequence selects the Windows code-page path; it also documents that a Rich Edit control can override the default treatment of larger values.[1]

This makes Alt Code a reusable domain-specific abstraction rather than a keyboard trick or list of memorized numbers. It predicts what must be inspected when an entry produces an unexpected symbol: whether the digits came from the numeric keypad, whether Alt remained held, whether the first digit was zero, which code page or input locale supplied the mapping, and whether the receiving control replaces the default handler. It also explains why apparently universal “Alt code charts” can mislead: a number is not self-interpreting.

The recognition boundary is deliberately platform-specific. Numeric Unicode entry on Unix-like desktops, a Compose sequence, a dead key, AltGr, a mobile long-press palette, and an application command such as hexadecimal-value-plus-Alt+X are neighboring input methods, not Alt Codes. They may share the prime pattern of Encoding and Decoding, but they do not reproduce this modifier-and-decimal-numpad protocol.

Structural Signature

  • the focused receiver — an application control or input context eligible to accept character input;
  • the keyboard state — Alt is held while the sequence is accumulated and its release terminates entry;
  • the numeric-keypad channel — digits arrive through keys recognized as keypad digits rather than an arbitrary row of number keys;
  • the decimal sequence — one or more ordered digits accumulated as a numeric value;
  • the prefix discriminator — in the inherited Windows convention, an initial zero distinguishes a Windows-code-page lookup from the legacy OEM path;
  • the interpretation context — code page, input locale, control implementation, and compatibility behavior that give the number meaning;
  • the reduction rule — some handlers restrict or wrap the accumulated value, while some Rich Edit contexts accept a wider range;
  • the mapping — the selected table or character space that relates numeric value to character;
  • the completion event — release of Alt triggers interpretation rather than inserting every digit literally;
  • the emitted value — a character or, in some legacy cases, a control value delivered to the focused receiver;
  • the compatibility obligation — modern implementations preserve historical sequences even while their native text model has changed;
  • the diagnostic trace — input path, prefix, value, code page, and receiver jointly explain the observed output.

Recognition requires the whole protocol. A shortcut such as Alt+F4 has an Alt modifier but no numeric character lookup. Typing a code point into a character-map utility has numeric identification but not the held-Alt/numpad state machine. A published “Alt code” without an interpretation context is an incomplete specification.

What It Is Not

  • Not a character encoding. A code page or Unicode supplies a mapping; Alt Code is an input protocol that selects and uses a mapping.
  • Not Unicode input in general. Many systems enter Unicode through hexadecimal sequences, input-method editors, compose facilities, or application commands.
  • Not a keyboard shortcut in general. Most Alt shortcuts invoke commands rather than accumulate a decimal character value.
  • Not Keyboard Accessibility. Keyboard Accessibility concerns complete, practical keyboard operation of an interface; Alt Code is one narrow method of producing text.
  • Not a keyboard layout. A layout maps ordinary key states to symbols; the Alt-code protocol overlays a numeric escape path.
  • Not AltGr. AltGr selects alternate layout levels and does not ordinarily interpret a decimal keypad sequence.
  • Not a dead key or Compose key. Those combine symbolic keystrokes rather than decode a decimal number under the Alt state.
  • Not Character Map. Character Map is a browsing and copy/insert tool, although charts may help a user discover numeric values.
  • Not a particular table of characters. Tables are context-dependent instances and can be wrong when their assumed code page or control is unstated.
  • Not guaranteed application-independent behavior. The receiving control may alter the default interpretation.[1][2]

Scope of Application

The home scope is IBM-PC-derived and Microsoft character input. Historically, the IBM PC BIOS accumulated decimal keypad input while Alt was held and supplied a byte to the keyboard buffer. The displayed glyph depended on the applicable hardware character generator and code page. Windows preserved the behavior for compatibility while adding a leading-zero convention for its then-current Windows code page.[1]

In contemporary Windows software, the protocol recurs in ordinary edit controls, Rich Edit controls, word processors, legacy applications, and compatibility-sensitive workflows. Microsoft’s Rich Edit documentation explicitly lists decimal Alt+0xxx behavior: values below 256 use an input-locale ANSI code page, while values above 255 insert a Unicode character in that control family.[2] Chen separately explains why the same large decimal sequence can be reduced modulo 256 by the default input system but modulo 65,536 by Rich Edit, producing different characters in different receivers.[1]

The abstraction covers OEM/no-leading-zero entry, Windows-code-page/leading-zero entry, and control-specific widened decimal handling as recognized variants because all preserve the defining held-Alt decimal-numpad transaction. An optional hexadecimal numpad mechanism, application-specific Alt+X conversion, and non-Windows Unicode entry are adjacent systems and should not be silently absorbed.

Clarity

“Alt code” is ambiguous between a protocol, a particular sequence, and a chart. This node denotes the protocol family. A token such as 0169 is only an instance under an assumed mapping. A chart is documentation. The recognizable abstraction is the transaction that converts a keypad number into a character when Alt is released.

The strongest diagnostic is contextual substitution. If entering the same digits in two receiving controls yields different output, yet both wait for Alt release, the protocol is still present and the handler or mapping has changed. If the digits appear literally as typed, the protocol did not engage. If the result invokes a menu command, the keystrokes were interpreted as an accelerator rather than numeric character input.

The word “code” also tempts a false equation with Unicode code point. Legacy Alt numbers may name positions in OEM or Windows code pages, and values may be reduced before lookup. Therefore “Alt+decimal Unicode code point” is not a safe universal description.

Manages Complexity

Alt Code compresses a multi-layer compatibility problem into named roles. Without it, an unexpected glyph looks random. With it, diagnosis separates keyboard event recognition, state accumulation, prefix selection, code-page mapping, value-width behavior, receiver override, and glyph rendering. Each layer suggests a different repair: use the keypad, correct the prefix, verify the input locale, choose a compatible control, or use a different Unicode input method.

It also explains compatibility debt. Preserving memorized DOS-era sequences required Windows to retain the OEM path while offering another route for its Windows code page. Later Unicode-capable controls widened interpretation without making every input surface uniform. The protocol therefore shows how a stable gesture can conceal multiple historical semantics.

Abstract Reasoning

  1. If the leading zero changes while digits and application remain fixed, a different mapping family may be selected and the output can change.
  2. If the code page changes while the numeric sequence remains fixed, the mapped character may change because the number alone lacks semantic completeness.
  3. If a value above 255 is accepted by Rich Edit but reduced by a default handler, the same sequence can yield different characters across controls.[1]
  4. If the top-row number keys are used where only keypad digits feed the accumulator, the protocol will not engage even though the visible numerals match.
  5. If Alt is released before all digits are entered, the early release completes one transaction; later digits belong to ordinary input or another command.
  6. If a chart omits its code-page assumption, successful use in one locale does not license a universal prediction.
  7. If a character is absent from the selected legacy code page, a legacy Alt path cannot reach it merely by knowing its Unicode code point.
  8. If an application intercepts the keystrokes as an accelerator, the operating-system-level character mapping may never receive the intended sequence.
  9. If a method takes hexadecimal digits after a separate mode trigger, it may be Unicode input but is not the ordinary decimal Alt-code variant.
  10. If a sequence continues to work after the underlying text system changes, compatibility emulation rather than unchanged internal representation may explain the stability.

Knowledge Transfer

The exact abstraction transfers among applications and Windows versions that implement the inherited Alt-numpad transaction. It is useful in documentation, technical support, localization testing, accessibility testing, and text-control engineering because it supplies a common recognition and failure vocabulary.

The portable skeleton—symbol intention encoded as digits, interpreted under a shared scheme, then decoded into a character—belongs to Encoding and Decoding. Other platforms can instantiate that prime without instantiating Alt Code. Treating every numeric character-entry method as an Alt Code would erase the very compatibility mechanism that makes this node informative.

Examples

  • OEM-style decimal entry: the user holds Alt, types a non-zero-prefixed decimal number on the keypad, and the default Windows path interprets it through the OEM compatibility mapping.
  • Windows-code-page entry: the user includes an initial zero, causing a value below 256 to be interpreted through the Windows/ANSI code page associated with the input locale.[1][2]
  • Rich Edit widened value: a decimal value above 255 can be treated by Rich Edit as a Unicode character, while another control can reduce the same value and produce a different result.[1]
  • localization test: a tester keeps the sequence constant while changing input locale, exposing that the prefix path relies on a different code-page mapping.
  • support diagnosis: digits typed on the main number row appear literally; the missing numeric-keypad role explains the failure.
  • non-example—Alt+F4: the modifier invokes an application command, not numeric character decoding.
  • non-example—Alt+X in Rich Edit: a previously typed hexadecimal value is converted through a distinct command rather than accumulated as decimal keypad input.[2]
  • non-example—Compose sequence: symbolic key composition can produce the same character but uses a different state machine and scheme.

Structural Tensions

  • backward compatibility vs. semantic uniformity — preserving legacy sequences helps experienced users while maintaining multiple mappings for visually identical gestures;
  • gesture stability vs. hidden context — the same motor sequence feels constant even as code page, locale, and receiving control alter its meaning;
  • compact entry vs. discoverability — memorized numbers are efficient but difficult to infer and easy to document without their assumptions;
  • application flexibility vs. predictable output — control-specific overrides widen character reach while breaking the expectation that the operating system interprets every sequence identically;
  • legacy byte spaces vs. Unicode coverage — old paths preserve installed practice but cannot uniformly express the contemporary character repertoire;
  • numeric precision vs. user-facing names — exact numbers support deterministic lookup only when the mapping is declared, whereas character names are portable but slower to enter;
  • keyboard reach vs. hardware dependence — the method reaches otherwise unavailable characters but commonly depends on numeric-keypad event semantics.

Structural–Framed Character

Alt Code is predominantly structural. Its roles and transitions—modifier state, ordered digit accumulation, termination, mapping selection, lookup, and emission—are mechanistic. The convention was historically designed and preserved, but recognizing an instance does not require a normative judgment. Locale and application context parameterize the mechanism rather than turn it into an evaluative category.

Structural Core vs. Domain Accent

The structural core is desired symbol + numeric representation + mode-signaling input state + context-selected decoder + emitted character. The domain accent is unmistakable: the Alt key, numeric keypad, decimal accumulation, IBM-PC inheritance, OEM and Windows code pages, input locale, and Windows control behavior. Removing that accent yields generic coded input or Encoding and Decoding, not a substrate-independent Alt Code.

  • Encoding and Decoding — the intended character is represented by a numeric code and recovered under a mapping shared between convention and handler.
  • Protocol — the gesture is an ordered transaction whose completion and interpretation depend on state.
  • Compatibility — later systems preserve earlier gestures while mediating changed internal representations.
  • Context — code page, locale, and receiver determine how the same digits are read.
  • State — Alt-down, accumulated digits, and Alt-up define a temporary input mode.

The minimal prospective DAG uses a composition edge to prime:encoding_and_decoding. The candidate specializes that reusable transform with platform-specific input roles and compatibility variants.

Relationships to Other Abstractions

Local relationship map for Alt CodeParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Alt CodeDOMAINPrime abstraction: Encoding And Decoding — is a kind ofEncodingAnd DecodingPRIME

Current abstraction Alt Code Domain-specific

Parents (1) — more general patterns this builds on

  • Alt Code is a kind of Encoding And Decoding Prime

    the intended character is represented by a numeric code and recovered under a mapping shared between convention and handler.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Alt Code sits in a sparse region of the domain-specific corpus (96th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With

  • Unicode code points or Unicode input generally;
  • OEM, ANSI, or Windows code pages themselves;
  • AltGr and keyboard-layout layers;
  • dead keys and Compose sequences;
  • input-method editors for complex scripts;
  • Character Map and symbol palettes;
  • hexadecimal Alt+X conversion;
  • numeric HTML character references;
  • application accelerators and ordinary Alt shortcuts;
  • Keyboard Accessibility as an interface-wide property;
  • a website’s context-free table labeled “Alt codes.”

References

[1] Raymond Chen, “The history of Alt+number sequences, and why Alt+9731 sometimes gives you a heart and sometimes a snowman,” The Old New Thing, Microsoft, July 2, 2024, https://devblogs.microsoft.com/oldnewthing/20240702-00/?p=109951. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h

[2] Microsoft, “About Rich Edit Controls,” Windows App Development documentation, especially “Rich Edit Shortcut Keys,” https://learn.microsoft.com/en-us/windows/win32/controls/about-rich-edit-controls. registry ↩a ↩b ↩c ↩d ↩e

[3] “Alt code,” Wikipedia, frozen revision 1358048686, https://en.wikipedia.org/wiki/Alt_code. registry