What does \x1b[A mean — move up 0 rows or move up 1 row?

Move up 1 row. Omitted CSI cursor-move parameters default to 1, not 0 (CUU / CUD / CUF / CUB / CHA / VPA all behave this way). So \x1b[A ≡ \x1b[1A, and \x1b[5A moves up 5 rows. This catches people coming from CUP, where omitted params default to 1 too but the absence implies 'home' rather than 'don't move'. See the csi-default-params pitfall.

Why doesn't \x1b[B (move down) go past the bottom of the screen?

Cursor-move sequences clamp to the visible region — they don't scroll. To scroll content up by one row at the bottom edge, use \x1b[S (SU, scroll up) or \x1b[M (RI, reverse index that scrolls down at the top). \x1b[B on the last row is a no-op; the cursor stays put. Same applies to CUF past the right edge.

CUU / CUD / CUF / CUB — Move cursor

Move the cursor up / down / right / left by N cells.

Byte forms

Every common string-literal form so you can paste-and-search either direction.

\\x1b[\x1b[NA (up; B down, C right, D left)

\\033[\033[1A

\\e[\e[1A

ESC [ESC [ N A

hex1b 5b <N> 41

Description

Four directional cursor-movement sequences sharing the \x1b[NX shape, distinguished by the final byte: A=CUU up, B=CUD down, C=CUF forward / right, D=CUB back / left. N is the number of cells to move and defaults to 1 if omitted (\x1b[A moves up one line, equivalent to \x1b[1A) — the ECMA-48 default-1 contract for missing parameters applies, and the csi-default-params pitfall documents why you should never emit \x1b[0A (zero is unstandardized: xterm clamps to 1, Linux console / fbcon treats as no-op, Apple Terminal.app drops it). The cursor stops at the edge of the addressable region — CUU / CUD do not scroll the viewport, and CUF / CUB do not wrap to the next line. If you need scrolling, use scroll-up-down (SU / SD); if you need absolute placement, use cursor-position (CUP).

The addressable-region boundary depends on the scroll region. If DECSTBM has narrowed the scroll region via \x1b[t;br, CUU stops at line t not line 1; CUF / CUB respect the rightmost / leftmost screen column unless DECOM (?6h) is active, in which case they respect the scroll-region origin. Linux console / fbcon implements all four directions correctly; ConPTY 1809+ forwards them through to the host terminal; tmux passes them through untouched; screen 4.x and 5.0 both handle them. The terminfo caps are cuu1 / cud1 / cuf1 / cub1 for the single-cell variants and cuu / cud / cuf / cub for the parametric ones — tput cuu1 is the portable shell-script way to spell \x1b[A without a hard xterm-256color assumption.

There is no "close" — these are state-free cursor moves, not toggles. The common idiom for in-place progress redraw is \r\x1b[K (carriage return + EL erase-to-EOL, see erase-line) rather than CUB to column 1; CUB N would leave whatever characters were already written to the right of the new cursor position. For multi-line progress displays, step up with \x1b[NA, redraw, then \x1b[NB (or implicit newlines) to return. If your TUI needs precise absolute placement that survives mid-draw scrolling, cursor-position (CUP \x1b[r;cH) is more reliable than chaining relative moves — terminal-side state can drift if a re-flow / resize happens between your CUU and a subsequent CUF.

Spec citation: ECMA-48 §8.3.22 (CUU) / §8.3.19 (CUD) / §8.3.20 (CUF) / §8.3.18 (CUB)

Parameters

A	up by N
B	down by N
C	right by N
D	left by N

Examples

bash

printf 'line1\nline2\033[1A\rCHANGED\033[1B\r\n'

python

import sys; sys.stdout.write('\x1b[2A')

fmt.Print("\x1b[2A")

javascript

process.stdout.write('\x1b[2A')

printf("\x1b[2A");

Used in

Real-world tools that emit this sequence — anchors the bytes to commands you've already used.

bash, zsh readlineleft/right arrow keys move the cursor inside the input buffer
vim, neovimall `h j k l` and motion redraws emit CUU/CUD/CUF/CUB on legacy terminals
ora, cli-spinnersCUU to step back over the spinner frame before redraw
htop, btop in-place stat redraws
tmux pane scrolling

Frequently asked

Short answers to the questions developers actually search for this sequence.

What does \x1b[A mean — move up 0 rows or move up 1 row?: Move up 1 row. Omitted CSI cursor-move parameters default to 1, not 0 (CUU / CUD / CUF / CUB / CHA / VPA all behave this way). So \x1b[A ≡ \x1b[1A, and \x1b[5A moves up 5 rows. This catches people coming from CUP, where omitted params default to 1 too but the absence implies 'home' rather than 'don't move'. See the csi-default-params pitfall.
Why doesn't \x1b[B (move down) go past the bottom of the screen?: Cursor-move sequences clamp to the visible region — they don't scroll. To scroll content up by one row at the bottom edge, use \x1b[S (SU, scroll up) or \x1b[M (RI, reverse index that scrolls down at the top). \x1b[B on the last row is a no-op; the cursor stays put. Same applies to CUF past the right edge.

Common typos / look-alikes

Wrong forms developers commonly paste from Stack Overflow that look right but aren't — with the canonical correction inline.

\x1b[0A\x1b[A
CUU / CUD / CUF / CUB treat 0 as 1 per ECMA-48 §8.3.22, but emitting 0 is misleading — the canonical form is no parameter (defaults to 1) or an explicit positive count. Some legacy parsers reject 0 outright.
\x1b[3a\x1b[3A
Final byte case matters — A is CUU (cursor up), lowercase a is HPR (horizontal position relative). Mixing them sends the cursor right instead of up. CSI final bytes are case-sensitive ECMA-48 dispatch keys.
\x1b3A\x1b[3A
The CSI introducer is ESC [ (two bytes), not bare ESC. Without the [, terminals try to parse ESC 3 as a one-byte escape (often a no-op or implementation-specific) and the A prints as literal text.

Terminal support

xterm: yes
Linux console (fbcon): yes
macOS Terminal.app: yes
iTerm2: yes
Windows Terminal: yes
cmd.exe / ConPTY: yes
kitty: yes
alacritty: yes
WezTerm: yes
Ghostty: yes
GNOME Terminal: yes
Konsole: yes
tmux: yes
GNU screen: yes

xterm	Linux console (fbcon)	macOS Terminal.app	iTerm2	Windows Terminal	cmd.exe / ConPTY	kitty	alacritty	WezTerm	Ghostty	GNOME Terminal	Konsole	tmux	GNU screen
yes	yes	yes	yes	yes	yes	yes	yes	yes	yes	yes	yes	yes	yes

Related sequences

In the family cookbook

CSI cookbook · 2. Cursor movement — CUU / CUD / CUF / CUB + CUP + CHA / VPA