Terminal color codes are decimal SGR (Select Graphic Rendition) parameters between 30 and 37, 40 and 47, 90 and 97, and 100 and 107 that select one of 16 palette slots on a terminal emulator. They are wrapped inside an escape sequence that starts with the ESC control byte (0x1B), an opening bracket, semicolon-separated parameter values, and a final m, so the byte stream looks like ESC[31m for a red foreground. The base 8 colors live at 30-37 for foreground and 40-47 for background in black, red, green, yellow, blue, magenta, cyan, and white order, and the xterm-compatible bright 8 live at 90-97 and 100-107. ECMA-48 defines the SGR control function and the basic rendition parameters, while xterm documentation cross-checks the widely implemented bright extensions. Color numbers select palette slots, not guaranteed RGB values; the actual hue is chosen by the terminal theme, user profile, accessibility setting, multiplexer, or remote environment that ends up reading the stream.
The 16-Color Palette and Its SGR Codes
Every modern terminal emulator implements at least these 16 palette slots because they are defined by ECMA-48 and extended in the xterm control sequence reference. The base 8 are the original ECMA-48 rendition parameters; the bright 8 are xterm-compatible extensions that most Linux and macOS terminals honor alongside Windows consoles that have virtual terminal processing enabled. The table below lists every code the ANSI Color Codes Generator searches and exposes, with the slot name on the left, the foreground code in the middle, and the background code on the right.
| Palette slot | Foreground | Background |
|---|---|---|
| Black | 30 | 40 |
| Red | 31 | 41 |
| Green | 32 | 42 |
| Yellow | 33 | 43 |
| Blue | 34 | 44 |
| Magenta | 35 | 45 |
| Cyan | 36 | 46 |
| White | 37 | 47 |
| Bright black | 90 | 100 |
| Bright red | 91 | 101 |
| Bright green | 92 | 102 |
| Bright yellow | 93 | 103 |
| Bright blue | 94 | 104 |
| Bright magenta | 95 | 105 |
| Bright cyan | 96 | 106 |
| Bright white | 97 | 107 |
Two style parameters are common enough to live alongside the colors. Bold is SGR 1, underline is SGR 4, and reset is SGR 0. Italic is SGR 3 and is preserved in the generator's internal compatibility logic even though the current interface does not expose it, so an italic code coming from another tool will still parse. Anything outside this small set, including 24-bit truecolor sequences, is rejected by the generator on purpose so the output stays ECMA-48 and xterm compatible. The color names above describe palette slots, not guaranteed RGB values, and the slot mapping can be remapped by themes, accessibility profiles, multiplexers, or remote environments on the receiving end.
Build and Copy a Sequence in Three Steps
- Open the ANSI Color Codes Generator, type the text you want to color into the input field, and pick an optional foreground and background from the dropdowns. Add bold or underline only if you actually need them, because each extra parameter is one more byte to ship and one more variable that downstream terminals may interpret differently.
- Read the visible escaped representation to verify the parameters, for example 1;4;91;44 for bold, underline, bright red foreground, and blue background, and confirm the raw SGR stream looks right. The visible form writes the escape byte as \x1b so the page itself does not change appearance when you preview the output.
- Click the copy button to place the raw ESC byte, parameter list, text, and trailing ESC[0m reset onto the clipboard, then paste it into a terminal-aware source string, fixture, log template, or debugging context. Test the reset behavior and the actual hue in the destination terminal, theme, and output mode your users actually run.
Anatomy of an SGR Stream
Every terminal color sequence follows the same byte pattern: the ESC control byte (0x1B, written as \x1b or ^[ in logs), a literal opening bracket [, one or more decimal parameters separated by semicolons, and the letter m that ends the SGR control function. ECMA-48 calls this the CSI m sequence, where CSI stands for Control Sequence Introducer. As a concrete example, the byte stream ESC[1;4;91;44mHELLO followed by ESC[0m emits HELLO in bold, underline, bright red on blue, and then resets graphic rendition so the next character is plain.
When parameters are stacked, the order does not change the visual result for the colors themselves, but the style parameters are conventionally listed first to make the stream readable when you are debugging it later. The reset, ESC[0m, is appended automatically by the generator whenever a prefix is generated, so a later log line is less likely to inherit your colors. The reset is a guardrail, not proof that every consumer will interpret the stream identically; some contexts will respect it, others may not, which is why a plain-text logging path is still a sensible default.
If you want the deeper format rules, the original ECMA-48 fifth edition defines SGR and the rendition controls, and the xterm control sequences reference documents the bright extensions that virtually every modern terminal implements. For a hands-on walkthrough that complements this overview, the SGR parameter format and safe-handling guide documents the same escape rules with concrete examples.
Where the Codes Actually Render
The 16 palette slots are nearly universal, but the colors you see on screen are not guaranteed. The SGR number selects a slot, and the terminal theme, user profile, accessibility settings, multiplexer mapping, or remote environment chooses the actual RGB value for that slot. A bright red on your laptop can look orange on a colleague's screen if they use a custom palette, and it can disappear entirely on a CI log viewer that strips control bytes. Some terminals also remap bold to increased intensity rather than a heavier font, and on a few older terminals bold toggled the bright palette instead of changing weight. Underline shape and color vary similarly, and italic support is spotty across implementations.
Windows consoles only honor these codes when virtual terminal processing is enabled, and NO_COLOR conventions can suppress them in tools that follow that standard. Redirected noninteractive output may also drop them, so a script that prints colors to a piped file may produce no visible styling on the receiving end. The browser cannot tell you which of these applies to your target, because the page has no terminal emulator and cannot determine whether the destination supports ECMA-48, xterm extensions, Windows virtual terminal, NO_COLOR, or piped stdout. Always test the actual application and provide a way to disable color for users who want it off.
Safe Handling for Logs and Shared Output
Raw escape bytes are control data, not text. Pasting them into a command line, log file, issue tracker, chat window, or source file can produce invisible behavior rather than readable characters. A single stray CSI sequence inside a log line can hide text, forge a visual line break, create a misleading link, or disrupt terminal state for the next reader. Many data leaks over the years have used exactly this trick, which is why mature logging libraries usually escape or strip control bytes before they reach disk and why interactive shells reset state aggressively after suspicious input.
Sanitize any untrusted input before printing it to an interactive terminal, and provide a plain-text logging path where control sequences are removed or visibly escaped. A user-supplied username, commit message, filename, or chat message that contains ESC[31m should never appear verbatim in a CI log, a shared terminal session, or a copied ticket. The generator keeps every byte local to your browser, never uploads or executes anything in a shell, and exposes the visible \x1b form precisely so you can review a sequence before copying it. For untrusted destinations, strip ESC and CSI before logging, or rely on a logging library that does so by default and that offers a plainly escaped mode for archived output.
For a deeper look, see ASCII Chart API Alternative: 128 Standard Codes Locally.