Terminal escape sequences are conditionally safe in logs: they are safe when every byte that reaches the log has been produced by a known source and verified by your application, and they are unsafe the moment untrusted text can be re-rendered with raw control bytes attached. The risk has nothing to do with the SGR parameter numbers themselves, which are standardized by ECMA-48 fifth edition and widely cross-checked against xterm control sequences documentation. The risk comes from pasting raw ESC[...m control bytes into a terminal that interprets them as commands. A malicious or simply dirty payload can hide text behind fake blanks, insert a line that overwrites a previous line, draw a clickable-looking hyperlink, or change the title bar of the host terminal long after the log viewer resizes its window. Logs that store raw bytes and then dump them into a TTY later face all of those problems. The safer pattern is to keep two paths: a colored path for terminal-aware consumers and a sanitized or visibly escaped path for archives, issues, chat messages, and shared files. The ANSI Color Codes Generator supports both paths by showing the sequence as a literal \x1b string that you can store, copy, and review without emitting any control character.
Why Raw Escape Sequences Are a Log Safety Problem
An SGR sequence starts with the escape byte, an opening bracket, semicolon-separated decimal parameters, and the letter m. The visible representation writes the escape byte as \x1b so the sequence can be reviewed without changing the appearance of a web page, but the moment that same byte reaches a terminal emulator it stops being printable text and becomes a control instruction. ECMA-48 standardizes that instruction; xterm and many other emulators implement it; Windows virtual terminal processing adds a comparable layer. What the instruction can do inside an interactive terminal is far broader than set a color: a control sequence can move the cursor, clear the screen, change the title bar, set the scrolling region, switch character sets, or trap the terminal in alternate screen mode.
When a log stores raw bytes and a downstream tool dumps them into a TTY, every one of those capabilities travels with the log line. An adversary who can inject into a log line can therefore forge visual output. A clean log line can be silently mutated by something that hides the original text behind fake blanks, overwrites it on the next line, draws an underlined word that looks like a hyperlink, or sets the terminal title to a confusing string. Plain-text logs are not interactive in any meaningful sense, but they become interactive the moment a developer re-opens them with cat, tail -f, less -R, an IDE console, or a chat client that interprets control bytes.
When ANSI Codes Belong in a Log — and When They Don't
The decision is rarely "color or no color" globally; it is "which sink will read this byte stream?". A TTY that supports ECMA-48, xterm extensions, and Windows virtual terminal processing can render SGR parameters meaningfully, and the same stream inside a redirected pipe, a JSON log aggregator, a CI artifact, a GitHub comment, a ticket body, or an email message looks like garbage at best and a security incident at worst. The NO_COLOR convention reserves the right for users and tools to disable color by environment variable, so any logger that emits raw bytes without honoring NO_COLOR also misbehaves for users who explicitly asked for plain text.
A workable rule for safe handling:
- Keep raw SGR bytes inside a single program that writes to a confirmed TTY and that uses an isatty-style destination check.
- Strip or visibly escape control bytes before they reach files, archives, and shared surfaces.
- Always append ESC[0m after a colored run so later output does not inherit the formatting. The generator appends a reset whenever a prefix is created; that reset is a guardrail, not proof that every downstream consumer interprets the stream identically.
- Offer a plain-text or visibly escaped logging mode, and switch to it the moment the log destination is unknown.
Build and Inspect an SGR Sequence Safely with the ANSI Color Codes Generator
This is the core workflow that keeps a generated sequence inside a safe boundary. Every step runs in the browser, so no bytes leave the page and nothing is uploaded or executed in a shell.
- Open the ANSI Color Codes Generator and enter the terminal text you want to format. Choose optional foreground, background, bold, and underline settings. The interface exposes three styles only: bold parameter 1, italic parameter 3 (kept in logic for compatibility), and underline parameter 4. Unsupported style and color numbers are rejected.
- Click Generate. The page renders two outputs. One is the visible escaped representation, where the escape byte shows as \x1b and the parameters are clearly readable. The other is the raw control-byte string that a terminal would interpret. Read the visible escaped form first to confirm the parameters are what you intended; this is the form safe to paste into a log file or issue comment.
- Copy the raw sequence only into a trusted terminal-aware context: a local source string, a debugging fixture, or an interactive terminal you control. Then test the reset behavior end to end. A bright red foreground with blue background, bold, and underline uses parameters 1;4;91;44, and the run should always end with ESC[0m so the next prompt returns to defaults.
All text, choices, generated bytes, search terms, and clipboard operations remain in the browser. The page has no terminal emulator, so it cannot determine whether a destination supports ECMA-48, xterm extensions, Windows virtual terminal processing, NO_COLOR conventions, or redirected noninteractive output. That confirmation has to come from the destination itself.
SGR Parameter Reference for the 16-Color Palette
| Color name (palette slot) | Foreground | Background | Bright foreground | Bright background |
|---|---|---|---|---|
| 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 |
Base foregrounds 30–37 and backgrounds 40–47 are normative SGR parameters from ECMA-48; the bright extensions 90–97 and 100–107 come from the xterm control sequences documentation and are mapped by every common terminal emulator that handles extended foregrounds. Color names here describe palette slots, not guaranteed RGB values. Terminal emulators, themes, user profiles, accessibility settings, multiplexers, remote environments, and applications can remap those slots, so the same parameter can render as different colors in different terminals.
Sanitization Patterns for Logs and Terminals
The safest handling pattern is to separate the colored output path from the archived output path and never let the two paths share a raw byte stream. For a deeper reference on SGR parameter format and on validating user-supplied SGR strings before emitting them, the guide ANSI Escape Codes: SGR Parameter Format and Safe Handling walks through the same boundary from a complementary angle.
Concretely, the patterns that work in production code:
- Detect the destination with an isatty-equivalent check before emitting colored output, and respect the NO_COLOR environment variable by stripping all SGR parameters when it is set.
- Strip or sanitize any user-supplied text that flows into a TTY. The minimum sanitization is to replace control bytes other than tab and newline with their caret notation or to remove them outright.
- Always close a colored run with the parameter 0 reset; the generator does this automatically. Without the reset, every line after a color tag inherits the formatting.
- Provide a visible-escape mode for logs and chat: replace the escape byte with \x1b and keep the readable parameter list. The visible-escape mode is exactly what the generator shows next to the raw sequence.
Beware of bold as a color hint: some older terminals use bold (parameter 1) to access a bright palette. Modern emulators usually treat bold as increased intensity, so a bold run in the same color produces a different visual result even with identical parameters. Underline shape and color also vary, so do not rely on them for semantic meaning.
Testing the Sequence in the Real Terminal
The visible-escape view is a sanity check, not a final test. Verify behavior in the actual terminal themes and output modes your users run. Practical tests you can run against a generated sequence:
- Pipe a generated raw sequence through cat -v to confirm the escape byte is visible as ^[.
- Open the same line in less -R and in less -R -+F to confirm the reset ends the colored run cleanly.
- Run inside tmux or screen to confirm the multiplexer does not leak the colored style into the next prompt.
- Check that the sequence still parses correctly after being JSON-encoded or base64-encoded and decoded; many serializers treat the escape byte specially.
- Confirm that redirecting the same output to a file drops the color or visibly escapes it, instead of leaving raw bytes inside the file.
The external fixtures shipped with the generator lock the base foreground and background pairs and enforce 16 unique code rows, one bright filter result, and an exact multi-style raw and escaped sequence. Those fixtures guard the generator itself; they do not validate any destination terminal. For reliable use, generate the smallest necessary parameter set, inspect the visible representation, copy only into a trusted context, reset formatting, and verify behavior in the real terminal themes and output modes your users run. Two paths — colored for confirmed TTYs, plain or visibly escaped for archives — keep raw control bytes inside one well-defined boundary.