Appearance
Terminal Standards
50 years of terminal protocols — from teletypes to GPU-rendered emoji
There is no single terminal standard. What exists is layers — ECMA-48 (1976) defined the grammar, DEC's VT series (1978–1993) implemented it, xterm extended it for decades, and modern terminals add new protocols. This page maps the archaeology. See the glossary for acronyms.
Formal standards vs de facto specs
Some entries below are formal standards (ECMA-48, Unicode). Others are hardware reference manuals (VT100–VT510), implementation documents (xterm ctlseqs), or protocol proposals (Kitty extensions). All have shaped how terminals work — but they carry different levels of authority.
The Layers of Terminal Standards
There is no single authoritative standard for modern terminals. What exists is a stack of layers, each building on the one before it, with increasing levels of vendor-specificity and decreasing levels of formal standardization.
At the base is ECMA-48 (1976) — the grammar. It defines how escape sequences are structured: CSI, OSC, DCS, and the parameter syntax that every terminal speaks. Above that sits DEC's VT series (1978–1993) — the implementations that made the grammar real. The VT100 became so dominant that "ANSI terminal" effectively means "VT100-compatible." Then comes xterm (1996-present) — Thomas Dickey's three-decade project that extended the VT model with truecolor, mouse tracking, and clipboard access. Finally, modern protocols like the Kitty keyboard protocol and inline graphics (Kitty, Sixel) push terminals beyond what the original standards ever imagined.
The messy truth: most of what developers call "ANSI escape codes" aren't ANSI at all. ANSI withdrew their terminal standard (X3.64) in 1994. What we actually use is a patchwork of ECMA-48 grammar, DEC private extensions, xterm innovations, and modern protocol proposals — held together by decades of copy-the-leader compatibility.
Example Sequences by Standard
| Standard | Example Sequence | Effect |
|---|---|---|
| ECMA-48 | ESC[1mBoldESC[0m | Bold — SGR text styling |
| VT100 | ESC[5;10H | Cursor to row 5, col 10 |
| VT220 | ESC[2P | Delete 2 characters at cursor |
| Xterm | ESC[38;2;255;0;0mRedESC[0m | Red — truecolor |
| Kitty | ESC[>1u | Unambiguous keyboard mode |
| OSC | ESC]8;;url\x07LinkESC]8;;\x07 | Link — hyperlinks |
Standards
ECMA-48 Standard1976
The grammar that started everything
60 features100% avg. adoption
VT1001978
The terminal that won
50 features98% avg. adoption
VT2201983
Editing operations arrive
4 features100% avg. adoption
VT5101993
DEC's late VT reference
10 features83% avg. adoption
DEC Private Modes1978+
The negotiation protocol
22 features96% avg. adoption
Xterm Extensions1996+
Thomas Dickey's 30-year legacy
33 features97% avg. adoption
Operating System Commands (OSC)1976+
Out-of-band communication
13 features86% avg. adoption
Kitty Extensions2017
The modern revolution
6 features79% avg. adoption
Sixel Graphics1983
Inline graphics, revived
2 features21% avg. adoption
Unicode1991+
The width problem
10 features79% avg. adoption
ECMA-48 (1976) — The Grammar That Started Everything
First published by ECMA International in 1976 (5th edition 1991), ECMA-48 defines the CSI (Control Sequence Introducer) grammar that every escape sequence uses. The ESC [ prefix, the parameter syntax, the SGR (Select Graphic Rendition) codes for text styling — all of it flows from this one document. It also defines cursor movement (CUP, CUU, CUD), erase operations (EL, ED), and scroll control.
Here's the irony: developers universally call these "ANSI escape codes," but the ANSI standard (X3.64) that referenced this work was withdrawn in 1994. The surviving standard is ECMA-48, maintained by ECMA International. ISO/IEC 6429 is the ISO equivalent. None of them have been updated since 1991 — the standard is frozen, while terminals continue extending the parameter space with vendor innovations.
"ANSI escape codes" aren't ANSI
ANSI published the X3.64 terminal standard in 1979, then withdrew it in 1994 in favor of the international ECMA-48 / ISO 6429. The name "ANSI escape codes" persists from 1979 — referring to a standard that no longer exists. What we actually use is ECMA-48 grammar with decades of vendor extensions.
VT100 (1978) — The Terminal That Won
The DEC VT100 ran on an Intel 8080 CPU with 3KB of RAM, yet it defined terminal computing for the next five decades. It implemented the ECMA-48 escape grammar, adding scroll regions (DECSTBM), character sets, and the private mode namespace (CSI ?) that terminals still use today. When software says it's "VT100-compatible," it's promising support for a specific set of behaviors that this $1,800 box established in 1978.
The VT100's dominance wasn't accidental — DEC shipped it with the rising tide of Unix, VAX/VMS, and networking. Every competitor had to emulate it. That gravity persists: every terminal emulator today is, at its core, a VT100 emulator with extensions.
Why is your terminal 80 columns wide?
IBM's 80-column punch card format (1928) set the width for the IBM 3270 terminal (1971), which the DEC VT100 adopted in 1978. The 24-row default comes from fitting 1,920 characters (80 x 24) into early memory architectures. Nearly 50 years later, 80x24 remains the default terminal size.
VT220 (1983) — Editing Operations Arrive
The VT220 added the insert/delete operations (ICH, DCH, IL, DL) that make full-screen terminal applications practical. Without VT220 editing sequences, programs like vim and tmux would have to redraw the entire screen for every character insertion. The VT220 also introduced 8-bit control codes, user-defined keys, and national replacement character sets.
These editing sequences are so fundamental that it's hard to imagine terminals without them — but they weren't in the VT100. The jump from VT100 to VT220 was the jump from a display terminal to an interactive editing terminal.
VT510 (1993) — DEC's Late VT Reference
The VT510 was one of DEC's later VT models; the VT520 and VT525 followed before DEC was acquired by Compaq in 1998. No modern terminal implements the full VT510 spec, but specific features like DECTCEM (cursor visibility) and DECSCNM (reverse video) became universal. The VT510 Reference Manual remains the most cited document for terminal implementors — it's the closest thing to a comprehensive reference for DEC escape sequences.
DEC Private Modes (1978+) — The Negotiation Protocol
DEC private modes use the ? prefix in CSI sequences to toggle terminal behaviors: CSI ? Pm h (DECSET) to enable, CSI ? Pm l (DECRST) to disable. This namespace is the primary mechanism for feature negotiation between applications and terminals. Cursor visibility (?25), auto-wrap (?7), alternate screen (?1049), mouse tracking (?1000–1006), bracketed paste (?2004), focus events (?1004) — all controlled via DEC private modes.
The "private" designation means vendor-defined: any terminal can allocate new mode numbers without conflicting with ECMA-48's standard modes. This extensibility is why DEC private modes remain the backbone of terminal feature control.
View DEC Private Modes features →
Xterm Extensions (1996+) — Thomas Dickey's 30-Year Legacy
One person — Thomas Dickey — maintains xterm, ncurses, AND the terminfo database. He's been doing it since 1996. The xterm control sequences document (ctlseqs) is the single most important reference for terminal developers, documenting not just xterm's behavior but the de facto standards the rest of the ecosystem follows.
Xterm became the reference for many widely deployed extensions, including 256-color support, the alternate screen buffer with cursor save, four mouse tracking modes, focus reporting, bracketed paste, OSC 8 hyperlinks, and OSC 52 clipboard access. Most features that developers think of as "standard" were actually xterm innovations that other terminals copied.
View Xterm Extension features →
One person maintains the terminal stack
Thomas Dickey has single-handedly maintained xterm, ncurses, and the terminfo database since 1996 — nearly 30 years. His xterm control sequences document (ctlseqs) is the de facto specification that every terminal implementor references. Most of what developers call "standard" terminal behavior was defined by one maintainer in one text file.
OSC — Operating System Commands (1976+)
OSC (Operating System Command) sequences use ESC ] for communication between applications and the terminal as an application. Unlike CSI sequences that control the display, OSC sequences talk to the host: window title (OSC 0/2), clipboard access (OSC 52), hyperlinks (OSC 8), color palette queries (OSC 4/10/11), semantic prompt markers (OSC 133), and notification (OSC 9/777).
The OSC namespace is open-ended — any terminal can define new number codes without conflicting with CSI-based controls. This makes it the preferred extension point for modern terminal features that don't fit the CSI model.
Kitty Extensions (2017) — The Modern Revolution
Kovid Goyal's Kitty terminal introduced protocols that solve fundamental limitations of the 1978-era terminal model. The Kitty keyboard protocol provides unambiguous, modifier-aware key reporting — solving a problem from 1978: Ctrl+I and Tab are the same byte (0x09) in traditional terminals. With the Kitty protocol, they're distinct events, and key-up events are reportable for the first time.
The Kitty graphics protocol enables inline image display via chunked base64 transfer. Kitty also defined extended underline styles (curly, dotted, dashed) with independent underline colors. These extensions have been adopted by Ghostty, WezTerm, foot, and other modern terminals — making them the closest thing to an emerging standard for next-generation terminal features.
View Kitty Extension features →
Why Kitty matters
Kitty significantly advanced terminal input by documenting key-release reporting and a comprehensive keyboard protocol. Earlier efforts like xterm's modifyOtherKeys and Leonerd's CSI u/fixterms addressed parts of this problem. Kitty's keyboard and graphics protocols are now adopted by Ghostty, WezTerm, foot, and others — making them the closest thing to an emerging standard for next-generation terminals.
Sixel (1983, Revived) — Inline Graphics
Sixel graphics were designed for dot-matrix printers in 1983. The format encodes raster images as printable ASCII characters, where each character represents a 1x6 pixel column — hence "six pixels." DEC included Sixel support in the VT240 and VT340 terminals for displaying charts and diagrams.
Sixel was largely dormant for decades until modern terminals (xterm, foot, WezTerm, mlterm, contour) revived it as a way to display inline images using only standard escape sequences — no terminal-specific protocol required. The Sixel vs. Kitty graphics debate is one of the liveliest in the terminal ecosystem: Sixel is older and more widely supported; Kitty graphics is more capable and purpose-built.
Unicode (1991+) — The Width Problem
Unicode's challenge for terminals isn't character encoding — UTF-8 is universal. The challenge is width calculation. East Asian characters (CJK ideographs) and many emoji occupy two terminal columns ("wide" or "fullwidth"), while most Latin/Cyrillic/Arabic characters occupy one. UAX #11 defines width classes, but terminals must also handle combining characters, variation selectors, zero-width joiners, and emoji sequences.
Incorrect width calculation causes cursor positioning errors, text misalignment, and broken TUI layouts. It's one of the hardest problems in terminal emulation because the Unicode Standard keeps adding new characters, and terminals, libraries, and the C wcwidth() function all update at different rates.