Most mistakes when generating ANSI color codes come from treating the escape sequence as an opaque string instead of a structured control message with a definite grammar. The SGR (Select Graphic Rendition) grammar, defined by ECMA-48 and extended by xterm, is strict: the Control Sequence Introducer must be the actual ESC byte followed by an opening square bracket, the parameters must be decimal integers separated by semicolons, and the sequence must terminate with the letter m. Get any of these pieces wrong, or forget the trailing ESC[0m reset, and the terminal will silently misrender your text, leak bold into every line that follows, or refuse to interpret the parameters at all. Because escape bytes are control data, a malformed sequence pasted into a log file or chat can hide text, forge visual lines, or break interactive terminal state for whoever scrolls past it. Each of these failure modes is preventable with a builder that validates parameters, exposes a visible representation, and appends a reset on your behalf.
Why Generating ANSI Color Codes Goes Wrong
SGR sequences look simple on the surface, but each piece of the string has a specific job. The ESC byte signals the start of a control sequence, not printable text. The opening bracket after the escape is what marks a CSI (Control Sequence Introducer) per the ECMA-48 specification. The decimal numbers select rendition parameters, not arbitrary styling. The letter m is the terminator that tells the terminal this is a Select Graphic Rendition command, distinct from cursor movement, screen clearing, or other CSI families. Drop any one of these and the terminal falls back to the most forgiving interpretation, which is usually "ignore the sequence entirely and print my text uncolored." When developers do see something rendered, the next failure mode is a leaked style: every line printed afterward inherits the last SGR state, because no ESC[0m reset was appended.
Another common mistake is treating color numbers as if they were RGB values. SGR codes 30 through 37 and 40 through 47 are palette slot indices, defined by ECMA-48 to select eight base colors in black, red, green, yellow, blue, magenta, cyan, and white order. The xterm-compatible bright extensions map 90 through 97 and 100 through 107 to the same color names in the same order. The actual rendered RGB is chosen by the terminal emulator, the active theme, the user's color profile, and the accessibility settings in use. Code 31 does not mean a specific shade of red; it means the slot the terminal is currently calling red.
A third class of mistake is invisible at build time but obvious at paste time. Raw escape bytes are control data. When they show up in a log file, a chat message, a code review, or a CI artifact, they can be interpreted by whichever terminal or pager opens them. That can hide characters, draw misleading red blocks that look like errors, or break the scrolling region of an interactive session. The error is invisible to the author and borne by the reader.
The Anatomy of a Correct SGR Sequence
A working SGR sequence has exactly six parts, in order:
- The ESC byte, the single control character 0x1B. In source code, this is written as the escape sequence "\x1b" or "\u001b", never the four characters backslash, x, one, b.
- The opening square bracket: [.
- One or more decimal integers separated by semicolons. Each integer is a parameter.
- The terminator letter: m.
- The text to be rendered.
- A trailing reset, again starting with ESC, then [0m.
The canonical order for parameters puts style codes before color codes. Bold is parameter 1, underline is parameter 4, and they combine with the foreground and background color codes. Foreground colors use 30 through 37 for the base palette and 90 through 97 for the bright palette. Background colors use 40 through 47 for the base palette and 100 through 107 for the bright palette. For a bold, underlined sequence with a bright red foreground and a blue background, the parameters are 1, 4, 91, 44, written as 1;4;91;44. The full string with the leading ESC shown as \x1b is \x1b[1;4;91;44mhello\x1b[0m, and that visible escaped representation is exactly what lets you review the sequence without triggering a color change in the surrounding page.
The full sixteen-color SGR reference, defined by ECMA-48 and extended by xterm, is:
| Slot | Foreground (base) | Foreground (bright) | Background (base) | Background (bright) |
|---|---|---|---|---|
| Black | 30 | 90 | 40 | 100 |
| Red | 31 | 91 | 41 | 101 |
| Green | 32 | 92 | 42 | 102 |
| Yellow | 33 | 93 | 43 | 103 |
| Blue | 34 | 94 | 44 | 104 |
| Magenta | 35 | 95 | 45 | 105 |
| Cyan | 36 | 96 | 46 | 106 |
| White | 37 | 97 | 47 | 107 |
Numbers outside this table, including 38 and 48 for non-palette color selection and their xterm extensions for 256-color and truecolor, are part of the broader SGR specification but are explicitly rejected by the generator's validation. Sticking to the 16 slots removes a class of mistakes where a consumer that does not implement those extensions prints the raw parameters as visible text instead of a color.
Build a Sequence Without Mistakes
The fastest way to avoid generation mistakes is to delegate the assembly to a builder that validates each piece. The ANSI Color Codes Generator follows this workflow:
- Enter the exact text you want styled in the text field. Plain ASCII is safest, and remember that the text is embedded inside the control sequence and travels with it.
- Choose an optional foreground color from the 16 palette slots. Skip the field if you do not want a foreground override.
- Choose an optional background color from the same 16 slots. Background and foreground can be set independently.
- Toggle bold and underline on or off. Bold maps to parameter 1 and underline maps to parameter 4; the two are independent and can be combined.
- Read the visible escaped representation. The escape byte is shown as \x1b, so the sequence reads as printable text in the browser and you can review it without changing the page's color.
- Inspect the SGR parameters listed next to the visible string. They appear in canonical order, separated by semicolons, and contain only numbers from the 16-color table plus style codes 1 and 4. Any unsupported combination is rejected before the sequence is built.
- Click Copy to place the raw control bytes on the clipboard. The button copies the actual ESC byte plus the bracket, the parameters, the terminator, your text, and the trailing ESC[0m reset, not the four characters \x1b.
- Paste the bytes only into a context that interprets them: a terminal multiplexer pane, a source file that will be run by a terminal-aware program, or a fixture in a debug session. Avoid pasting them as raw bytes into a log, an issue tracker, or a chat.
If the visible representation shows \x1b[1;4;91;44m followed by your text and ending in \x1b[0m, the structure is correct. The only remaining questions are about the destination terminal, not the sequence itself.
Mistakes That Break Logging and Security
A control sequence that worked perfectly in your terminal can become a small attack surface the moment it lands somewhere it does not belong. Logs containing untrusted control bytes have been shown to hide text, forge visual lines that scroll past the real message, create misleading clickable links, and disrupt terminal state by switching character sets or resetting the screen. The mistake here is twofold: emitting raw bytes into a log, and emitting untrusted user input back through a terminal without first sanitizing it.
The right discipline is to keep two paths. The first is the styled, terminal-aware path, where the generator's raw bytes are appropriate. The second is a plain-text path for logs, issues, CI artifacts, and chat, where every control byte is either stripped or visibly escaped as \x1b. Most logging libraries accept a non-color formatter for exactly this reason, and the ECMA-48 specification treats the ESC byte as the start of a control sequence, not as printable content. Treat any untrusted text the same way: never let user input flow into the styled path without filtering, and never let your own styled output flow into the plain path without stripping or escaping the control bytes.
A related mistake is assuming the generator's visible escaped representation is safe to paste everywhere. It is not. The visible representation writes the escape byte as the four characters \x1b, so a browser or text editor displays them literally. A terminal-aware consumer, however, will see the underlying ESC byte and interpret the whole sequence. The Copy button deliberately copies the raw bytes, while the visible representation is for review only. Use the visible representation in documentation, tests, and tickets, and reserve the raw bytes for contexts that will render them.
Mistakes That Depend on the Terminal, Not the Code
A perfectly valid SGR sequence can still render wrong, and the mistake usually lies in assuming one terminal speaks for all of them. Bold is the canonical example: in many terminals, parameter 1 selects an increased-intensity color rather than a heavier font weight, and in some older terminals it switches the foreground to the bright palette. If your code is meant to render in both a modern graphical terminal and a TTY session over SSH, design for the lowest common denominator and verify the actual rendering in both.
Color names describe palette slots, not guaranteed RGB values. The same code 91, bright red foreground, can render as a vivid tomato red in a Solarized Light theme and a desaturated brick red in a Solarized Dark theme, and the value can be remapped further by accessibility settings, multiplexer passes, and remote environment variables. The NO_COLOR convention, honored by most modern CLIs, requests that the program emit no color codes at all, and the terminal's virtual terminal processing mode on Windows determines whether SGR sequences are interpreted at all. None of these are visible in the generated bytes; they are visible only in the rendered output. Test in the actual environments your users run, and provide a documented way to disable color for the NO_COLOR and noninteractive cases.
The same caveat applies to underline. Parameter 4 enables underlining, but the line shape, straight, curly, double, or dotted, and the underline color are chosen by the terminal, not by your code. If underlining matters semantically, such as marking a link, a deleted line, or a warning, do not rely on shape or color to convey it. Use the text alongside the style, and test with a screen reader or accessibility filter where the underline may be invisible or repurposed.
Verifying the Sequence Before You Ship It
Three checks catch the majority of mistakes before they reach a user. First, the structural check: confirm the raw bytes on the clipboard start with the ESC byte, followed by [, then a string of decimal digits and semicolons, then m, then the text, then ESC again, then [0m. The visible escaped representation in the generator is the easiest way to do this without exposing your terminal to a malformed sequence. Second, the semantic check: confirm the parameter list is the smallest necessary set, that style codes come before color codes, and that every color code is in the 16-color table. Third, the destination check: paste the raw sequence into the same terminal emulator, theme, and output mode your users will run, and confirm the reset actually returns later output to the default rendition.
The generator handles the structural and semantic checks on your behalf by validating the input, rejecting unsupported style and color numbers, ordering the parameters canonically, and appending a reset every time a prefix is created. The destination check is yours. The reset is a guardrail, not a guarantee, and the browser has no way to know whether the destination supports ECMA-48, xterm extensions, Windows virtual terminal processing, NO_COLOR conventions, or redirected noninteractive output. Treat the generator as a way to remove the assembly mistakes, then verify behavior in the real terminal that will actually render your output.