ANSI color codes are the SGR parameters for foreground or background palette changes, while bold and underline are separate SGR style parameters. ANSI escape codes cover a wider range of terminal operations, while SGR is the Select Graphic Rendition family and color parameters are one part of it. If the requirement is to move a cursor, clear a region, or control another non-rendering behavior, adding color parameters does not solve that job. If the requirement is a red status label, a colored background, bold emphasis, or an underline, then the relevant SGR parameters are part of the solution. The decision therefore has two parts: identify the visual change you actually need, then confirm that the destination interprets SGR and permits color. The ANSI Color Codes Generator helps with the first part by building a sequence from terminal text plus optional foreground, background, bold, and underline settings. It also provides a searchable reference for the standard eight plus bright eight palette slots. It does not inspect your destination or promise that every terminal will render the same colors, so the second part still requires testing the real application, terminal theme, and output mode.
Separate color codes from other ANSI controls
An ANSI escape sequence is a control instruction, and not every instruction changes color or text style. SGR controls graphic rendition, with foreground color, background color, bold, and underline represented by specific parameters. A sequence that moves the cursor or clears a display is solving a different job, so adding color parameters to it would be redundant at best and misleading at worst.
Color codes are also optional within an SGR sequence. Bold and underline use SGR parameters too, so a sequence can emphasize text without selecting any foreground or background color. Conversely, choosing a foreground or background changes a palette slot rather than guaranteeing a particular RGB value. The generator targets this narrower formatting decision instead of building unrelated terminal controls.
Each generated sequence uses one CSI m prefix, places the supplied text after it, and appends ESC[0m to reset the graphic rendition. That reset is a guardrail that makes later terminal output less likely to inherit formatting; it is not proof that every terminal or application interprets the stream identically.
Translate the intended result into a concrete choice
Before opening a generator, describe the required result in plain language. The smallest valid choice usually follows directly from that description.
| Scenario | Relevant choice | What to select | Important caveat |
|---|---|---|---|
| A status label needs a red foreground | Foreground color | Choose a foreground and omit the background unless it is required | The terminal theme determines the palette slot's actual appearance |
| A panel needs contrasting colors | Foreground and background | Choose both colors | Themes and user settings can remap both slots |
| A warning needs stronger emphasis | Bold | Choose bold without adding color unnecessarily | Bold may increase intensity rather than select a heavier font |
| A label needs an underline | Underline | Choose underline by itself or with other required styles | Underline shape and color can vary by terminal |
| The output must move a cursor or clear a region | No color code | Use the appropriate non-color terminal control | This generator creates SGR rendition sequences, not general terminal-control sequences |
| The output is a human-readable log | Usually no raw styling | Remove control sequences or make them visibly escaped | Raw control data can distort logs or terminal state |
| The user or application has disabled color | No foreground or background color | Honor the destination's preference | The generator cannot detect this setting |
The tool can build the supported SGR combination that expresses a stated visual need. It cannot decide whether the destination should receive that combination. That second decision depends on the application, terminal, user preferences, and output channel.
Generate and test a suitable color sequence
- Enter the exact terminal text. This becomes the text placed between the opening SGR sequence and the reset. Keep it short enough to identify the intended part of the output.
- Choose only the required foreground, background, bold, and underline settings. Leave foreground and background unset when the output needs only emphasis or when no styling is necessary. The current interface exposes bold and underline; unsupported style and color numbers are rejected rather than silently accepted.
- Generate the sequence and inspect both outputs. Review the visible escaped representation and the SGR parameters. The visible representation writes the escape byte as \x1b, allowing you to examine the control structure without changing the browser page's appearance. The page deliberately avoids a fake color preview that could imply a universal terminal palette.
- Copy the raw sequence only into a trusted terminal-aware context. The Copy button places the actual ESC control byte, SGR parameters, text, and reset on the clipboard, not the four visible characters that spell \x1b. Use it in a suitable source string, terminal-aware tool, fixture, or debugging workflow rather than pasting it anywhere indiscriminately.
- Test the sequence and its reset in the actual application. Confirm that only the intended text receives formatting, that following output returns to normal, and that the result behaves correctly in the relevant terminal themes and output modes. Provide a way for users to disable color if the application supports styled output.
Match palette choices to SGR parameters
The ECMA-48 fifth edition defines SGR and the base rendition controls, while the xterm control sequences documentation cross-checks the widely implemented bright mappings. The generator keeps each foreground and background code explicit in its searchable 16-color reference.
| Palette slot | Base foreground | Bright foreground | Base background | Bright background |
|---|---|---|---|---|
| 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 |
These names describe palette slots, not guaranteed RGB values. Terminal emulators, themes, user profiles, accessibility settings, multiplexers, remote environments, and applications can remap them. Bold may select increased intensity instead of a heavier font, and some older terminals use bold to access a bright palette. Underline shape and color also vary between consumers.
For example, a bright red label on a blue background with bold and underline uses the SGR parameters 1;4;91;44. Its visible escaped form is \x1b[1;4;91;44mLabel\x1b[0m: the prefix selects both styles and colors, the label follows, and the reset ends the formatted span.
Test the destination, not just the generator
The generator has no terminal emulator, so it cannot determine whether a destination supports ECMA-48, xterm bright extensions, Windows virtual terminal processing, NO_COLOR conventions, or redirected noninteractive output. A sequence that renders correctly in one interactive terminal can still appear as plain text when output is redirected, filtered, or handled by an application that does not pass control sequences through.
Test the actual application in every mode that matters to your users. Check the normal terminal theme, any alternate high-contrast or accessibility configuration, and noninteractive output paths. Also verify that the reset prevents later output from inheriting formatting and that the application can disable color when requested. These checks answer the second half of the decision: not just whether the sequence is syntactically suitable, but whether styled output is appropriate for that destination.
Keep raw sequences out of untrusted logs
Raw escape bytes are control data, not ordinary printable characters. Pasting them into a terminal command line, log, issue, chat, or source file may produce invisible behavior rather than readable characters. Untrusted control characters can hide text, forge visual lines, create misleading links, or disrupt terminal state. Sanitize untrusted data before printing it to an interactive terminal and provide a plain-text logging path where control sequences are removed or visibly escaped. For a focused review of these risks, see handling ANSI escape sequences safely in logs.
The generator's text, choices, generated bytes, search terms, and clipboard work remain in the browser. Nothing is uploaded or executed in a shell, but that does not make an escape sequence safe to insert into an untrusted output stream. Safety still depends on where the copied sequence goes and how the receiving system treats control characters.
Use a repeatable color-code decision
Apply this checklist before adding ANSI color codes to an escape sequence:
- State the required visual outcome in plain language.
- Separate the need for text rendition from the need for cursor, screen, or other terminal controls.
- Confirm that the destination handles SGR and that color has not been disabled.
- Leave every optional foreground, background, bold, and underline setting unset unless it contributes to the stated outcome.
- Inspect the visible escaped representation and SGR parameters before copying.
- Copy the raw sequence only into a trusted terminal-aware context.
- Verify the formatting, reset, and subsequent output in the real application.
- Sanitize untrusted terminal content and maintain a plain-text logging option.
If those checks pass, generating the smallest suitable SGR sequence is appropriate. If the color is unnecessary, disabled, unsupported, or unsafe for the destination, leave the color parameters out without removing any independently required bold or underline styles.
If you're weighing options, Code Snippet Image Maker: PNG Rendering Explained covers this in detail.