Cool Easy

← All articles

How to share terminal output with colours intact

Terminal output looks great in the terminal. The moment you copy it anywhere else — a GitHub issue, a Slack message, a doc — the colours disappear and ANSI codes turn into garbage. Here's how to fix that.

5 May 2026 · 5 min read

Why copying terminal output breaks the colours

When you look at terminal output — a colourful test run, a git diff with red and green lines, a Docker build log with status indicators — you're seeing your terminal emulator interpreting invisible formatting codes embedded in the text. Those codes are called ANSI escape sequences.

They look like this in raw form: \033[0;32m (ESC followed by [0;32m). The terminal sees that sequence and switches to green text. Everything after is green until it sees a reset code.

When you copy that text and paste it into Slack, a GitHub issue, a Google Doc, or anywhere that isn't a terminal, the app just renders the raw characters. The ESC character either disappears silently or renders as a question mark, and the rest of the codes — [0;32m, [1;31m, [0m — appear as literal text. Your coloured output becomes either plain monochrome or a mess of bracketed numbers.

There's no one right fix. The correct approach depends on where you're sharing and why the colour matters.

The system

Step 1: Decide what the colour is communicating

Not all coloured output needs colours in the shared version. Start here:

Colours for emphasis (warnings in yellow, errors in red): a screenshot or rich HTML preserves this. Or just describe the warning in words — "the third line shows a red error for missing config" is often more useful than the colour itself.

Colours for structure (test results with green/red pass/fail): the most common case. A screenshot captures the visual clearly; an HTML export is searchable and copyable.

Colours for diffs (git diff, patch output): GitHub and GitLab render diff syntax-highlighting natively in their diff views. If you're showing a diff, paste it in a fenced code block with the diff language tag:

```diff
- old line
+ new line
```

Most platforms render this with green/red colouring without needing ANSI.

Colours you don't actually need: the output is important but the formatting is decorative. Strip the codes and share plain text — it's the most portable option.

Step 2: Convert ANSI to HTML with Toolbelt

For cases where the colour genuinely matters and you need something more shareable than a screenshot, Toolbelt's terminal formatter converts ANSI output to HTML.

Open Toolbelt's side panel, go to the terminal formatter, and paste your output. Toolbelt converts the ANSI codes into actual HTML colour formatting. From there you can:

The conversion runs in your browser. Your terminal output (which might include stack traces, credentials, or internal paths) doesn't go anywhere.

Step 3: For GitHub and GitLab — use code blocks

GitHub and GitLab markdown don't render ANSI colour in code blocks. The options for sharing coloured output in issues and PRs:

For test results and build logs: attach a screenshot. Add an alt text description of the key information ("Test run showing 3 failures: login_test, auth_test, session_test").

For diffs: use the diff fenced code block (shown above) — most platforms render it with green/red.

For long logs: use GitHub Gist — create a .txt file there and link to it. It's not coloured, but it's better than a wall of text in an issue.

For HTML-rendered output: host the .html file on any public URL and link to it in the issue. GitHub Pages, a private Gist (linked but not embedded), or a static host all work.

Step 4: For docs and internal tools — use rich text or screenshots

For internal documentation, Notion, Confluence, or Google Docs:

If you're documenting a CLI tool and want the output to look right in the docs, consider switching to a terminal theme with high contrast (dark background, clear colour separation) before screenshotting. A consistent look across all your CLI documentation is worth more than perfect ANSI fidelity.

For automation: ansi2html and aha

If you're generating HTML terminal output programmatically — for a CI report, a build log viewer, or an internal tool — command-line converters handle it:

ansi2html (Python):

pip install ansi2html
# Pipe output through it
your_command | ansi2html > output.html

aha (macOS/Linux):

brew install aha
your_command | aha > output.html

Both convert ANSI codes to HTML spans with inline styles. Useful for generating coloured log files in CI pipelines.

Common mistakes

Pasting terminal output into a GitHub issue expecting colours. GitHub markdown doesn't render ANSI. It will show the escape codes as garbage. Use a fenced code block for plain text or a screenshot for colour.

Screenshotting at low resolution. A blurry screenshot of an error message or stack trace is harder to read than the plain text it replaced. Zoom in or increase your terminal font size before screenshotting.

Sharing logs that contain credentials or secrets. Stack traces, environment dumps, and verbose logs frequently contain API keys, tokens, database URLs, and internal paths. Review what you're sharing before pasting it anywhere — especially into a public GitHub issue or a shared Slack channel.

Using a white terminal theme and wondering why the screenshot looks wrong. Many colour schemes assume a dark background. A white terminal screenshot is fine, but make sure your theme is consistent — mixing dark and light screenshots in the same documentation looks unprofessional and is harder to read.

Embedding a long raw log in a GitHub issue. Walls of text in issues make triage harder. Use a collapsible <details> block if you need to include a long log inline:

<details>
<summary>Full build log</summary>

your log here


</details>

FAQ

What are ANSI escape codes and why do they show up as garbage?

ANSI escape codes are character sequences — starting with ESC (character 27) followed by brackets and numbers — that tell a terminal emulator how to format text: colour, bold, underline, blink. Most apps outside a terminal (browsers, word processors, Slack) don't interpret them, so the raw codes appear as visible characters. ESC[0;32m, for example, is "set text colour to green" — it looks fine in a terminal that renders it, but turns into visible noise everywhere else.

What's the right way to share terminal output on GitHub?

Plain text in a fenced code block is the most compatible option for GitHub issues and PRs. GitHub doesn't render ANSI colours in markdown. If the colours are essential to understanding the output (a diff, a test result with red/green status), use a screenshot with alt text, or link to an HTML file with colour preserved.

Can Toolbelt also render markdown?

Yes — Toolbelt's text formatter handles both ANSI terminal output and markdown. Paste markdown and it renders with syntax-highlighted code blocks, proper headings, and formatted lists. You can copy the rendered output as rich text, plain text, or download as HTML or markdown.

What if my output has ANSI codes but I just want plain text?

Toolbelt can strip the ANSI codes and return clean plain text as well as render them. If you're sharing in an environment where you just want the text without codes or colour, stripping is usually cleaner than screenshot-ing.

Does Toolbelt need to send my terminal output anywhere to convert it?

No. The conversion is entirely client-side — your terminal output (which may contain sensitive logs, credentials in stack traces, or proprietary information) stays in your browser.