An ANSI color code is a Select Graphic Rendition (SGR) parameter such as 31 for red foreground, 44 for blue background, or 1 for bold, prefixed by the escape byte ESC, an opening bracket, semicolon-separated decimal numbers, and the letter m — for example, ESC[1;4;91;44m turns on bold and underline with bright red text on a blue background. The right approach to generate these sequences depends on what you actually need: a static reference for memorizing codes, a runtime library for production code, or a builder that produces raw control bytes you can paste into a terminal-aware context. A browser-based generator such as the ANSI Color Codes Generator fits the third category — it assembles the exact CSI m prefix, the text, and the trailing ESC[0m reset so you can copy raw bytes without a server upload, without installing a package, and without claiming a universal RGB palette.
Common Approaches to Generate ANSI Color Codes
Developers reach for one of three patterns when they need colored terminal output. Each has a distinct shape, and the choice matters because the sequence you generate is a stream of control bytes, not a styling object.
- Hand-coded lookup. You memorize or keep a cheat sheet of SGR numbers and write sequences such as "\x1b[31merror\x1b[0m" directly in source. This is fastest when the codes are stable, the palette is small, and you control the consumer.
- Language or framework library. Libraries such as colorama, chalk, rich, termcolor, or platform-specific wrappers abstract the escape bytes behind function calls. They handle cross-platform quirks such as Windows virtual terminal processing and often expose 256-color and truecolor helpers.
- Browser-based sequence builder. A static page like the ANSI Color Codes Generator accepts text plus optional foreground, background, bold, and underline settings, emits the exact CSI m prefix and ESC[0m reset, and copies the raw control bytes. Nothing is uploaded, so it doubles as a fixture maker for tests and as a teaching aid.
When a Browser-Based SGR Builder Is the Right Fit
A builder earns its place when you need the exact control bytes in front of you, want to avoid pulling a dependency, or want to teach the format without a runtime in the way. It is also useful when you are writing tests, debugging a log file, or building a fixture string that another tool will consume. The trade-off is scope: the generator supports the standard 8 plus bright 8 SGR palette and three text styles (bold, italic in logic, underline, with the current interface exposing bold and underline). It rejects unsupported numbers and avoids truecolor or 256-color parameters because it does not claim a universal color table.
If your project genuinely requires per-channel RGB or 256 indexed colors, a library that targets a specific terminal grammar is a better fit. If your goal is a copy-ready sequence you can paste into a source string, terminal-aware tool, or fixture, the builder is the simpler path. It also keeps the workflow honest: the visible page does not pretend to render the color, because no preview can faithfully represent every theme, multiplexer, or remote shell a user might run.
Build and Copy a Sequence in the ANSI Color Codes Generator
- Open the ANSI Color Codes Generator and enter the terminal text you want to render.
- Choose an optional foreground and an optional background from the standard or bright palette, and toggle bold or underline when needed.
- Generate the sequence and inspect two outputs side by side: the visible escaped representation, where the escape byte appears as \x1b so the browser page is not itself recolored, and the raw SGR parameter list such as 1;4;91;44.
- Use the Copy button to put the raw control-byte string on the clipboard. The clipboard contains the actual ESC byte, the SGR parameters, your text, and the trailing reset — not the four visible characters backslash-x-1-b.
- Paste only into a trusted terminal-aware context — a source string, a fixture, a debugging tool, or a redirect-aware shell — and verify the reset restores default rendition. For the parameter format itself, the ANSI escape codes SGR parameter format guide covers the same grammar in more depth.
The Standard 16-Color SGR Code Reference
The base foreground codes run 30 through 37 and backgrounds run 40 through 47, in the order black, red, green, yellow, blue, magenta, cyan, and white. ECMA-48 defines the SGR control, and xterm-style terminals extend it with bright foregrounds 90 through 97 and bright backgrounds 100 through 107. The table below lists each palette slot with both its base and bright SGR numbers so a generated sequence can be read at a glance.
| Color slot | Foreground (base) | Background (base) | Foreground (bright) | Background (bright) |
|---|---|---|---|---|
| Black | 30 | 40 | 90 | 100 |
| Red | 31 | 41 | 91 | 101 |
| Green | 32 | 42 | 92 | 102 |
| Yellow | 33 | 43 | 93 | 103 |
| Blue | 34 | 44 | 94 | 104 |
| Magenta | 35 | 45 | 95 | 105 |
| Cyan | 36 | 46 | 96 | 106 |
| White | 37 | 47 | 97 | 107 |
The SGR parameter numbers above follow the ECMA-48 standard for Select Graphic Rendition, with the bright extensions documented in the xterm control sequences reference. Color names label palette slots rather than fixed RGB values; terminal themes, user profiles, accessibility settings, multiplexers, and remote environments can remap each slot independently. Bold may map to increased intensity rather than a heavier font, and some older terminals use bold to reach a bright palette. Treat the codes as identifiers, not colors, and test the actual destination before relying on a specific visual result.
Verify and Reset the Sequence After Generation
Every prefix the generator builds is followed by ESC[0m, which resets graphic rendition so later terminal output does not inherit the formatting. The reset is a guardrail, not a guarantee: a destination may still interpret the stream differently or skip the bytes if it is not interactive. Generate the smallest necessary set of parameters, inspect the visible representation, copy only into a trusted context, and verify behavior in the real terminal themes and output modes your users run. The browser deliberately avoids displaying a fake color preview that would imply one universal palette, because no such palette exists across emulators. The page has no terminal emulator of its own, so it cannot determine whether a destination supports ECMA-48, xterm extensions, Windows virtual terminal processing, NO_COLOR conventions, or redirected noninteractive output.
Keep Terminal Output Safe After You Generate a Sequence
Raw escape bytes are control data, not display text. Pasting them into a terminal command line, a log file, an issue tracker, a chat window, or a source file can produce invisible behavior rather than readable characters. Untrusted control characters in logs can hide text, forge visual lines, create misleading links, or disrupt terminal state, so 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. The safe handling guide for SGR sequences in logs walks through concrete mitigation patterns and failure modes to watch for in production.
Other guardrails to keep in view: respect the NO_COLOR convention when it is set, test redirected and noninteractive output where escape bytes often appear as garbage rather than styling, and provide a way to disable color so screen readers and accessibility profiles are not forced to interpret stream bytes. All text, choices, generated bytes, search terms, and clipboard operations stay in the browser; nothing is uploaded or executed in a shell, which makes the builder safe to use on sensitive fixture data as long as the final destination is itself trusted.