ASCII, ANSI and Unicode art: choose an output that survives copying

If text art looks right in a generator but falls apart in a message or README, check the destination’s font and wrapping first. The characters need fixed-width cells, preserved spaces and enough room for each line. A fenced code block is a useful starting point in Markdown.

Choose the output for where it will be viewed. Plain text, coloured terminal output and a PNG preserve different things.

ASCII, Unicode and ANSI describe different choices

ASCII art uses basic characters such as letters, punctuation and spaces. It avoids the need for block or box-drawing glyphs, but it still needs suitable layout to stay aligned.

Unicode art can use characters such as █, ▓, ░ and ┌. These give useful shading and outlines when the destination’s font supports them at the expected width.

ANSI art uses terminal control sequences for formatting such as colour and cursor positioning. “ANSI” does not mean that the visible characters must all be ASCII. Terminal formatting and character encoding are separate parts of the display.

The ASCII art generator has text-banner and image-conversion modes. Text mode uses FIGlet fonts; image mode samples the picture and replaces its tones with characters.

Pick a width that fits the destination

Start with a modest number of columns and check the result where it will be used. More columns can show more detail, but a wrapped line breaks the image’s layout. A wide desktop preview does not establish that the same text will fit in a narrow chat pane.

For scale, 100 columns across 40 lines is 4,000 character cells before line breaks or Markdown fences. That is already too large for a 2,000-character message allowance. Message limits vary by service and account; the generator’s Discord preset uses a 2,000-character warning.

Sending a text file avoids the message-length limit, but the recipient still needs a suitable font and a viewer that preserves spacing.

Use the ramp to control light and dark areas

A character ramp orders glyphs by how much of a cell they cover. In a dark-on-light rendering, @ can represent a dark patch, while . or a space represents a light patch.

The generator’s standard ramp is @%#*+=-:. followed by a space. That last space lets the lightest areas remain blank. The detailed and Unicode block ramps provide other visual treatments; more steps do not guarantee a clearer result in every font or at every width.

Use Invert if light and dark regions appear reversed for your chosen foreground and background. Compare a recognisable feature in the source image with the output rather than assuming every dark background needs the same setting.

Brightness, contrast and gamma can bring out a subject lost in the background. Change one at a time so you can see what helped. Edge emphasis can suit line work but can also make a photograph busier.

Character cells change the proportions

A text cell is taller than it is wide in many monospace fonts. Giving a square source image equal numbers of columns and rows would make it look tall and narrow in such a font.

The local image converter uses a fixed correction of 2.1, so a square image at 100 columns produces 48 rows. This is an approximation for its display, not a measurement of every recipient’s font. If the shape changes after copying, check font size and line spacing as well as width.

Preserve the spacing and escape the destination’s syntax

For Markdown or GitHub, choose the corresponding code-block preset. It keeps whitespace and uses a fence longer than any run of backticks in the artwork, so those backticks do not end the block early.

For HTML, choose the HTML export. It wraps the content in a <pre> element and escapes characters such as < and &. Pasting raw artwork into an HTML document can otherwise turn part of it into markup.

For source-code comments, use the matching preset. A raw */ sequence inside a JavaScript block comment would close it; the generator alters that sequence. The Python and shell presets prefix each line with #. Check the generated comment in its actual language before saving it.

Unicode adds a further layout check. A missing glyph can be drawn by a fallback font with different dimensions, and some characters occupy more than one terminal column. For a destination you cannot test, a basic ASCII ramp reduces that dependency.

Keep colour only where it is supported

Plain-text and Markdown exports contain characters, not the image’s per-character colours. In image mode, the coloured HTML and ANSI exports can carry colour when colour output is enabled.

The ANSI exporter adds 24-bit foreground-colour codes and resets. The receiving terminal needs to support those codes; an ordinary text viewer may show them literally. Arbitrary ANSI files can contain other terminal instructions, so viewing an unknown file is not the same as displaying inert plain text.

Use PNG when the layout matters more than editable text

The generator can render the artwork to PNG, fixing the glyph positions and colours into pixels. Its PNG export uses a black background, so inspect the saved image and its light/dark treatment before sending it.

A PNG avoids font substitution and text wrapping, but the characters are no longer selectable as text. Include a short description if the image communicates something the reader needs to understand without seeing it.

Sources and further reading

• ECMA-48 — terminal control functions
• Unicode — Block Elements chart
• Unicode Standard Annex #11 — East Asian Width
• The FIGfont specification — text-banner font format and layout
• Paul Bourke — character ramps and aspect-ratio considerations
• OWASP — escaping output for its HTML context

Last reviewed 2 October 2026.