Appearance
Terminal Features โ
148 features across 13 categories โ tested across major terminal emulators
Most terminal features โ color changes, cursor moves, mode switches โ are controlled by escape sequences, byte patterns your terminal interprets instead of displaying. Some features (text wrapping, character width, scrollback behavior) are behavioral properties that terminals implement without explicit control sequences. This page catalogs them all, with support data from major terminals. See the glossary for acronyms.
How Escape Sequences Work โ
Most terminal features are controlled by escape sequences โ special byte patterns that tell the terminal to do something other than display text. When a program writes \x1b[1m, it's not printing four characters; it's telling the terminal "make the following text bold." The terminal intercepts the pattern, changes its internal state, and displays subsequent characters accordingly. Some features below are behavioral properties โ like text wrapping and character width โ that terminals implement without explicit control sequences.
The CSI (Control Sequence Introducer) ESC [ (hex 1b 5b) is the prefix for most sequences. What follows the CSI determines the operation: SGR (m suffix) for text styling, CUP (H suffix) for cursor positioning, DECSET (?...h) for enabling modes. Parameters are semicolon-separated numbers. Sub-parameters (colon-separated, from ECMA-48 but rarely used until Kitty adopted them) enable richer expressions like 4:3 for curly underline.
ECMA-48 defines a family of control-sequence formats (CSI, OSC, DCS, and others); terminals differ mainly in which parameters and functions they implement. The complexity lives in which parameter values each terminal recognizes โ and that's exactly what terminfo.dev measures.
Escape Sequences in Action โ
| Sequence | Renders | Feature |
|---|---|---|
ESC[1mHelloESC[0m | Hello | Bold (SGR 1) |
ESC[3mHelloESC[0m | Hello | Italic (SGR 3) |
ESC[4mHelloESC[0m | Hello | Underline (SGR 4) |
ESC[38;2;255;100;0mHelloESC[0m | Hello | Truecolor |
ESC[5;10H | cursor jumps to row 5, col 10 | Cursor Position |
ESC[?1049h | screen clears | Alternate Screen |
ESC[6n | terminal replies ESC[24;80R | Cursor Report |
ESC[>1u | keyboard sends unambiguous keys | Kitty Keyboard |
TIP
In practice, control sequences use the 7-bit form starting with ESC (byte 0x1B). ECMA-48 also defines 8-bit C1 forms (e.g., CSI as 0x9B), but they're rarely used. Your terminal processes thousands of these per second โ a single screen redraw in vim or htop can involve hundreds of cursor moves, color changes, and text writes, all encoded as these tiny byte patterns.
Categories โ
SGR (Text Styling)29 features
35 ways to style text, and terminals disagree on at least 5 of them
Top:iTerm2 (100%), Ghostty (100%), VS Code (100%)
Cursor17 features
15 sequences for moving a blinking rectangle around a grid
Top:VS Code (100%), Warp (100%), Cursor (100%)
Text16 features
The fundamentals: output, wrapping, wide characters, tabs
Top:iTerm2 (100%), Ghostty (100%)
Erase11 features
Surgical removal of characters, lines, and screens
Top:iTerm2 (100%), Ghostty (100%), VS Code (100%)
Editing5 features
Insert and delete โ the sequences that make vim possible
Top:iTerm2 (100%), Ghostty (100%), VS Code (100%)
Modes15 features
The terminal's settings panel, controllable via escape sequences
Top:iTerm2 (100%), Ghostty (100%), VS Code (100%)
Scrollback9 features
The least standardized area of terminal emulation
Top:iTerm2 (100%), Ghostty (100%), VS Code (100%)
Reset4 features
Returning the terminal to a known state
Top:iTerm2 (100%), Ghostty (100%), VS Code (100%)
Extensions19 features
Where the standard ends and innovation begins
Top:iTerm2 (89%), Ghostty (74%), VS Code (74%)
Character Sets4 features
Box-drawing characters from the VT100 era
Top:iTerm2 (100%), Ghostty (100%), VS Code (100%)
Device Status9 features
How applications ask "who are you?" and "where am I?"
Top:iTerm2 (89%), Ghostty (78%), VS Code (67%)
Input Protocols6 features
Enhanced keyboard and mouse reporting beyond VT100
Top:iTerm2 (100%), Ghostty (100%), VS Code (100%)
Unicode4 features
East Asian width, emoji, and the cursor alignment problem
Top:iTerm2 (100%), Ghostty (100%)
SGR (Text Styling) โ The Most Common Escape Codes โ
SGR (Select Graphic Rendition) sequences control every visual aspect of text: bold, italic, underline (5 styles including curly, dotted, and dashed), 256-color and truecolor (24-bit RGB) foregrounds and backgrounds, strikethrough, overline, and inverse video. SGR uses the m suffix: ESC[1m for bold, ESC[38;2;255;0;0m for red truecolor foreground.
Support ranges from universal (bold, basic 8 colors) to inconsistent (curly underline with independent underline color, overline). The curly underline (SGR 4:3) is especially interesting โ it uses ECMA-48's colon sub-parameter syntax that was largely ignored for decades until Kitty adopted it.
Cursor โ Positioning and Visibility โ
Cursor sequences handle positioning (CUP, CHA, CNL), visibility (DECTCEM), shape (DECSCUSR โ block, underline, bar, blinking variants), and save/restore (DECSC/DECRC). The cursor position report (DSR 6) lets applications ask "where is the cursor?" โ essential for terminal capability detection and shell integration.
Differences in DECSC/DECRC behavior (what exactly gets saved and restored) and cursor shape support are common sources of cross-terminal bugs in TUI applications.
Text โ Output Fundamentals โ
The basics of terminal text: output, wrapping at line boundaries, wide character handling (emoji and CJK ideographs that occupy two columns), tabs, backspace, and line control (IND, NEL). These are the features that every terminal application depends on, even if it doesn't know it.
Wide character handling is deceptively hard. When an emoji occupies two columns, what happens when it's at the last column of a line? Different terminals wrap differently, and the wrong behavior breaks every TUI layout that renders near the right edge.
Erase โ Surgical Content Removal โ
Line erase (EL 0/1/2), screen erase (ED 0/1/2/3), and character erase (ECH) allow applications to clear portions of the screen without redrawing everything. ED 3 (erase scrollback) is notable โ it clears the scroll buffer, which is useful for security (clearing sensitive output) but not universally supported.
Editing โ Insert and Delete โ
ICH, DCH, IL, and DL are the VT220 editing sequences that make full-screen terminal applications practical. Insert Character (ICH) pushes existing text right to make room; Delete Character (DCH) removes and shifts text left. Without these, every text change would require redrawing the entire line or screen.
These sequences are used by virtually every TUI application: vim, tmux, less, htop, every readline-based shell prompt. They're so fundamental they're easy to take for granted.
Modes โ Terminal Behavior Toggles โ
Terminal modes toggle global behavior: alternate screen buffer (?1049), bracketed paste (?2004), mouse tracking (four variants: X10, normal, button-event, any-event), focus events (?1004), auto-wrap (?7), and synchronized output (?2026). Mode support varies significantly across terminals.
The alternate screen is what makes it possible to run vim, then exit and see your shell exactly as you left it. Bracketed paste prevents pasted text from being interpreted as keyboard commands. These aren't obscure features โ they're what makes modern terminal usage safe and ergonomic.
Scrollback โ The Least Standardized Area โ
Scroll buffer behavior, reverse index, total line tracking, and alternate screen interaction. Scrollback handling is one of the most inconsistent areas of terminal emulation โ terminals differ in buffer size limits, whether alternate screen content enters scrollback, and how reverse index interacts with scroll regions.
Reset โ Returning to Known State โ
SGR attribute reset (SGR 0), full terminal reset (RIS), soft reset (DECSTR), and programmatic reset. How reliably can an application return the terminal to a clean state? Differences in what RIS resets โ cursor position, modes, scroll regions, character sets โ can cause subtle bugs that only manifest when switching between applications.
Why do terminals disagree on emoji width?
A single displayed emoji may be one codepoint or a longer grapheme cluster but should occupy 2 terminal columns. The wcwidth() function (from 1988) predates emoji entirely. Different terminals use different Unicode versions for width tables, and there's no standard for grapheme cluster width. This is why TUI layouts break with emoji.
Extensions โ The Cutting Edge โ
The Kitty keyboard problem
Traditional terminals can't distinguish Ctrl+I from Tab โ they're the same byte (0x09). The Kitty keyboard protocol fixes this by sending unambiguous key reports with modifier information. It's being adopted across Ghostty, WezTerm, foot, and other modern terminals.
Modern terminal extensions beyond the traditional VT specification: Kitty keyboard protocol (unambiguous key reporting), Kitty graphics and Sixel (inline images), OSC 8 hyperlinks (clickable links in terminal output), text reflow on resize, and semantic prompt markers (OSC 133). These features vary widely in adoption and represent the frontier of terminal capability.
Graphics โ Inline Images โ
Sixel (1983, revived) and Kitty graphics protocol (2017) enable inline image display in terminals. Graphics support remains fragmented โ some terminals intentionally avoid image protocols for security or complexity reasons. Sixel is older and more widely supported; Kitty graphics is more capable and purpose-built.
Character Sets โ Box-Drawing from 1978 โ
The DEC Special Graphics set (activated with ESC ( 0) provides box-drawing characters used by legacy TUI applications for borders and frames. Modern terminals default to UTF-8, making explicit character set switching rare โ but the DEC Special Graphics set remains in active use by programs that need to work on the widest range of terminals.
View Character Set features โ
Device Status โ Terminal Identification โ
Applications use DA1 (Device Attributes) to identify terminal type and capabilities, and DSR (Device Status Report) to query cursor position and terminal health. These query-response sequences are the foundation of terminal capability detection โ TUI frameworks use them at startup to determine what features are available.
View Device Status features โ
Input Protocols โ Beyond VT100 Keyboard โ
Modern input protocols provide richer keyboard and mouse reporting than the VT100's original scheme. Mouse tracking comes in six variants (X10, normal, button-event, urxvt, SGR, pixel). Keyboard enhancement protocols (modifyOtherKeys, Kitty keyboard) provide modifier-aware key reporting and key release events โ capabilities that were simply impossible in the original terminal model.
View Input Protocol features โ
Unicode โ The Width Problem โ
East Asian ambiguous character width, wide character wrapping, and tab stop behavior with mixed-width text. Getting Unicode right is essential for TUI applications to maintain proper cursor alignment across scripts and character sets. When a terminal miscalculates the width of an emoji or CJK character, everything to the right of it shifts โ breaking layouts, misaligning columns, and corrupting displays.
How Features Get Tested โ
Every feature on terminfo.dev is tested by sending actual escape sequences to real terminals and measuring the response. There are no self-reported capability databases or spec-sheet claims โ only observed behavior.
For terminal applications (Ghostty, iTerm2, Kitty, etc.), the community CLI (npx terminfo.dev) sends escape sequences to the real terminal and verifies behavior via cursor position reports, device attribute queries, and rendered width measurements. These results reflect what users actually experience.
For headless backends (xterm.js, vterm, Alacritty parser, etc.), Termless runs automated probes against headless terminal emulator libraries. Each probe sends an escape sequence and reads back the terminal state programmatically. A headless pass means the parser accepts the sequence โ not necessarily that it renders correctly in the visual terminal.
The combination captures both dimensions: community probes test what users see, headless probes test parser correctness and help library authors verify conformance.