How to Make an ASCII Text Banner for a README or Terminal

Open the source of almost any long-lived command-line program and you will find a block of letters drawn with slashes, underscores and pipes. That style comes from FIGlet, a small program written in 1991 by Glenn Chappell and Ian Chai, and its font format is still what text banners are made from today. The appeal has not changed: a banner made of characters survives anywhere text does - a terminal, a README, a log file, a commit message - with no image to host or break.

This guide walks through making one that looks right where it ends up, which is where most banners go wrong.

Step by step

1. Keep the text short. A banner is a logo, not a sentence. One to three words is the sweet spot; each letter can be six to ten characters wide, so a twelve-letter word in a large font is already wider than most terminals.
2. Choose the font for the place it will live. Compact fonts such as Standard read well in code comments. Heavy block fonts like ANSI Shadow suit a CLI start-up screen. Decorative fonts look good on a slide and terrible in a narrow README column. The ASCII Art Generator has 30 FIGlet fonts and a gallery that shows your own text in each of them, which is faster than guessing from names.
3. Fit it to a width. Eighty columns is still the safe assumption for terminals and many code style guides; GitHub renders wider, but a banner that fits 80 works everywhere. Pick a spacing mode to tighten it: fitted letters sit close, smushed letters share an edge, full width gives every letter its own cell.
4. Copy it as plain text. Colour in a preview is only decoration. What you paste must be uncoloured characters, otherwise you get escape codes or nothing at all.
5. Paste it inside a code block or comment. This is the step that decides whether it survives (see below).

Why banners break after you paste them

Every character in a banner has to sit in an exact column. Three things undo that:

• Proportional fonts. In a normal font an i is narrower than an m, so the columns drift. Banners only line up in a monospaced font.
• Collapsed whitespace. Markdown, HTML and many chat apps squash runs of spaces into one. The banner's left side survives and the right side caves in.
• Trimmed trailing spaces. Some editors strip spaces at line ends; harmless for most banners, fatal for fonts that rely on them.

The fix is the same in every case: wrap the banner in something that preserves text exactly.

Where to put it

1. README.md - inside a fenced code block (three backticks on the line before and after). GitHub and GitLab then render it in a monospaced font with spaces intact. Copying as a Markdown code block does the fencing for you.
2. Source code - inside a block comment at the top of the file. Check your formatter will not re-indent the comment.
3. A CLI tool's start-up - as a multi-line string printed once. Keep it under 80 columns and consider skipping it when output is not a terminal, so piped output stays clean.
4. Plain-text email - only if you know recipients read plain text; most mail clients show proportional fonts by default.
5. Anywhere styling is not under your control - export a PNG instead. It loses the "it is just text" advantage but always looks the way you made it.

A few design habits that help

• Test the banner at the narrowest width it will appear. If it wraps, choose a narrower font before shrinking the text.
• Use uppercase for heavy fonts; many decorative FIGlet fonts were drawn with capitals in mind.
• A frame or border makes a banner feel finished in a terminal but doubles its width cost; skip it in narrow contexts.
• Keep the generator settings (font and spacing) in a comment next to the banner, so the next person can regenerate it after renaming the project.