What's the maximum image size a Sixel terminal can render in one DCS sequence?

There's no spec-mandated cap — Sixel images stream pixel-row groups inside one DCS envelope (\x1bPq … \x1b\\) so the limit is the terminal's pixel-buffer allocation. Practical ceilings: xterm uses decGraphicsMaxSize (default 1000×1000) and silently truncates beyond; mlterm / WezTerm / Konsole / foot accept multi-megapixel images bounded only by RAM; Windows Terminal added Sixel in v1.22 with a soft 10 MP cap. Performance — not the spec — is the real limiter: a 4K full-screen image is ~2 MB of base-6-encoded payload that the terminal decodes serially while blocking the input loop.

Why does my Sixel image render as gibberish in tmux even though the terminal supports it?

tmux historically strips DCS payloads — Sixel arrives as \x1bP…\x1b\\ and tmux's parser eats both the introducer and the terminator, leaving the base-6 body to land as literal characters. Two fixes: (1) set -g allow-passthrough on plus wrapping each Sixel in \x1bPtmux; \x1b\\ (the tmux; passthrough envelope, with inner \x1b doubled to \x1b\x1b); (2) since tmux 3.4, native Sixel support is opt-in via set -g sixel on — no passthrough envelope needed. Use option 2 if you're on 3.4+; option 1 is the only path on older versions.

DCS Sixel — Inline raster graphics (ESC P q … ESC \)

Embed pixel images in the terminal stream using the Sixel device-control payload.

Byte forms

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

\\x1b[\x1bPq <sixel data> \x1b\\

\\033[\033Pq … \033\\

\\e[\eP q … \e\\

ESC [ESC P q DATA ESC \

hex1b 50 71 ... 1b 5c

Description

Sixel is a DEC-era inline pixel graphics format (DEC VT240/VT340) revived by modern terminals. The frame begins with the Device Control String introducer \x1bP (DCS), an optional parameter run, the q final byte that selects Sixel mode, then a payload of ?..~ printable characters where each byte encodes a 6-pixel-tall vertical slice (hence 'sixel'). The frame ends with the String Terminator — either \x1b\\ (ST, spec-correct) or \x07 (BEL, widely accepted). libsixel, chafa, viu, timg, ranger-style image previews, kitten icat --transfer-mode=stream (Sixel fallback for Kitty's native protocol), and mpv --vo=sixel all emit this sequence. Terminal support varies: xterm needs +sb compile and -ti vt340, mintty + foot + wezterm + iTerm2 + Windows Terminal Canary + ghostty work out of the box, kitty + alacritty + macOS Terminal do not (Kitty has its own better protocol).

Spec citation: DEC VT340 Programmer Reference / xterm-ctlseqs (DCS Ps; Ps; Ps q)

Examples

bash

# A 12x6 magenta block via the Sixel raw payload\nprintf '\033Pq#0;2;100;0;100#0~~\033\\'

python

import sys; sys.stdout.write('\x1bPq#0;2;100;0;100#0~~\x1b\\')

fmt.Print("\x1bPq#0;2;100;0;100#0~~\x1b\\")

javascript

process.stdout.write('\x1bPq#0;2;100;0;100#0~~\x1b\\')

printf("\x1bPq#0;2;100;0;100#0~~\x1b\\");

Used in

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

libsixel + `img2sixel` CLIlibsixel is the reference encoder — `img2sixel input.png | cat` produces a `\x1bPq…\x1b\\` DCS stream that any sixel-aware terminal (xterm `+T --tn xterm-direct`, mlterm, foot, WezTerm with `enable_kitty_graphics=false`) renders inline. libsixel also powers most other tools' sixel output paths via dynamic linking
gnuplot `set terminal sixel`gnuplot 5.4+ supports `set terminal sixel size 800,600` for inline plot rendering in the terminal — useful in scientific pipelines where you want to glance at a generated plot during a long-running fit without opening an X11 window or saving to PNG
ranger / mc image previewranger (with the `img2sixel` preview script) and Midnight Commander on sixel-capable terminals render image-file previews inline in the right pane. Preferred over kitty-graphics for portability — sixel runs on xterm / mlterm / foot / WezTerm / Windows Terminal ≥ 1.22 / Black Box, broader than kitty-graphics' kitty / WezTerm / Ghostty trio
matplotlib `mpl_sixel` backendPython: `import matplotlib; matplotlib.use('module://mpl_sixel'); plt.plot([1,2,3]); plt.show()` renders the plot as sixel directly in the Jupyter-less terminal — popular in HPC contexts where Jupyter is unavailable but interactive numeric work still happens at the shell
Black Box / Windows Terminal sixel previewBlack Box (GNOME terminal emulator built on VTE 0.73+) and Windows Terminal 1.22+ added native sixel rendering — `cat photo.six` displays inline. Both ship sixel-aware test patterns in their CI to catch regressions; integrators target these as the modern reference renderers

Frequently asked

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

What's the maximum image size a Sixel terminal can render in one DCS sequence?: There's no spec-mandated cap — Sixel images stream pixel-row groups inside one DCS envelope (\x1bPq … \x1b\\) so the limit is the terminal's pixel-buffer allocation. Practical ceilings: xterm uses decGraphicsMaxSize (default 1000×1000) and silently truncates beyond; mlterm / WezTerm / Konsole / foot accept multi-megapixel images bounded only by RAM; Windows Terminal added Sixel in v1.22 with a soft 10 MP cap. Performance — not the spec — is the real limiter: a 4K full-screen image is ~2 MB of base-6-encoded payload that the terminal decodes serially while blocking the input loop.
Why does my Sixel image render as gibberish in tmux even though the terminal supports it?: tmux historically strips DCS payloads — Sixel arrives as \x1bP…\x1b\\ and tmux's parser eats both the introducer and the terminator, leaving the base-6 body to land as literal characters. Two fixes: (1) set -g allow-passthrough on plus wrapping each Sixel in \x1bPtmux;<escaped>\x1b\\ (the tmux; passthrough envelope, with inner \x1b doubled to \x1b\x1b); (2) since tmux 3.4, native Sixel support is opt-in via set -g sixel on — no passthrough envelope needed. Use option 2 if you're on 3.4+; option 1 is the only path on older versions.

Common typos / look-alikes

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

\x1bPq...payload...\x1b\\ (lowercase q immediately after P with no Ps)\x1bP0;0;0q...payload...\x1b\\ (Ps1=0 macro mode, Ps2=0 background colour mode, Ps3=0 horizontal grid)
Sixel's DCS frame is \x1bP<Ps1>;<Ps2>;<Ps3>q<sixel-data>\x1b\\ — the q is the FINAL byte (introducer letter signalling "this is sixel"), but Ps1 / Ps2 / Ps3 parameters before it control macro / background / grid behaviour. Omitting them works on xterm (defaults applied) but breaks on some libsixel-based renderers that require explicit values. The most common surprise: Ps2=0 means "use the current SGR background colour for transparent pixels", but the default is implementation-defined — Black Box renders the sixel on a literal black backdrop, kitty renders on the terminal background. Always emit \x1bP0;0;0q or \x1bP0;1;0q (Ps2=1 = pixel position remains, transparent stays transparent) explicitly.
use 0–255 RGB triplets for the sixel palette: #1;2;255;0;0use DEC HLS percent-scaled values: #1;2;0;100;100 (P=1=red, H=0°, L=100%, S=100%) or #1;2;100;0;0 if specifying RGB mode (Ps=1=RGB in some libsixel forks)
Sixel palette colours use DEC's HLS model with percent-scaled values 0–100, NOT 0–255 RGB. #<P>;2;<H>;<L>;<S> sets palette slot P to HLS triplet where each value is 0–100. The 2 after the first ; is the colour mode — 1 = HLS, 2 = RGB on DEC VT340 hardware but 2 = HLS-equivalent on some libsixel variants (confusion source). Emitting #1;2;255;0;0 for red gets clamped to #1;2;100;0;0 on conforming renderers (so still red-ish) but Black Box and Windows Terminal 1.22 silently render it as black (value out of range → 0). The robust pattern is to scale RGB 0–255 to HLS first using colorsys.rgb_to_hls() (Python) or equivalent.
rely on terminal-side line-height: printf '\x1bP0;0;0q<image>\x1b\\\\\n' && next_cmdafter the sixel ST, emit \n for each text row the image consumed, then \x1b[<rows>B to move cursor below the image — or use kitty's \x1b[<row>;<col>H to absolute-position after
Most sixel implementations leave the cursor at the row where the sixel STARTED, not below the image — kitty (sixel mode), xterm, foot, wezterm, Black Box. If you write next_cmd after the sixel without manual row advance, it overwrites the bottom of your image. The terminals that DO advance the cursor (Windows Terminal 1.22, Mintty) put it at the start of the next line, but still overlapping with your image's pixel rows. Robust pattern: compute rows = ceil(image_pixel_height / cell_pixel_height) (cell pixel height comes from xterm's font metrics or DECRQM \x1b[?16$p cell-pixel report), then emit \x1b[<rows>B\r after the sixel ST. Or use \x1b[s before / \x1b[u after for save+restore (DECSC/DECRC pair).

Terminal support

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

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

Related sequences

In the family cookbook

DCS cookbook · 2. Pictures inside the stream — Sixel and Kitty graphics