Skip to content

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 โ€‹

SequenceRendersFeature
ESC[1mHelloESC[0mHelloBold (SGR 1)
ESC[3mHelloESC[0mHelloItalic (SGR 3)
ESC[4mHelloESC[0mHelloUnderline (SGR 4)
ESC[38;2;255;100;0mHelloESC[0mHelloTruecolor
ESC[5;10Hcursor jumps to row 5, col 10Cursor Position
ESC[?1049hscreen clearsAlternate Screen
ESC[6nterminal replies ESC[24;80RCursor Report
ESC[>1ukeyboard sends unambiguous keysKitty 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.

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.

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.

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.


Powered by Termless
Playwright for Terminals