FIGlet Banners: Why ASCII Art Breaks on Paste
ASCII art is stored character by character rather than drawn by an algorithm, which is why it needs a monospace font at both ends and collapses the moment you paste it into a chat client. The fonts, the joining rules and the paste traps are below; to draw one right now, the ASCII Text Generator linked from this guide turns words into a banner instantly.
Free and instant, with the ten classic fonts compiled in, and the output copies as plain characters you can paste straight into a README or a terminal.
turn words into a FIGlet banner in your browser →The whole thing in thirty seconds
Type Hi, pick the Standard font, and you get a six-line banner with the H and the i drawn in hashes and slashes, ready to copy. Switch to Slant and the same two letters lean right like italics. Switch to Bloody and they drip. That is the entire tool: words in, a banner out, ten fonts to choose between. The rest of this guide is about picking the right one and keeping it intact after you copy it, because a banner that breaks on paste was never really generated — it was only previewed.
What a FIGlet font actually is
FIGlet letters are not drawn by an algorithm; each one is stored, character by character, in a font file that dates the format to the early nineties. A font file contains a complete alphabet where every glyph is a small fixed-width picture made of printable characters, plus rules for how glyphs join — whether the space between an A and a V tucks in or stands apart, which is called smushing. The tool here ships ten of those files compiled in: Standard, Big, Slant, Small, Doom, ANSI Shadow, 3-D, Star Wars, Graffiti and Bloody. Because the glyphs are stored rather than computed, output is identical everywhere the same font file is used, and the Standard rendering here matches the command-line program exactly.
Picking the right font for the job
Standard is the default for a reason: medium height, clean lines, readable at a glance, and narrow enough that real words fit in an eighty-column terminal. Big doubles the presence for titles and MOTD screens but a ten-letter word will overflow, so reserve it for short names. Slant leans every glyph right and reads as emphasis, good for headers inside scripts. Small is the pragmatic choice when width matters more than drama — log banners, compact headers, anywhere Big will not fit. Doom, Star Wars, Graffiti and Bloody are novelty faces: perfect for a personal dotfiles header or a joke commit, wrong for anything someone else must read quickly. ANSI Shadow and 3-D add depth with shading characters, which survive only where the full character set renders, so test them in the actual target before committing.
Where banners survive, and where they die
The rule is one sentence: monospace in, monospace out. Terminals, code editors, plain-text files, markdown fenced code blocks and README files rendered as code all preserve the columns the art depends on. What kills it is proportional rendering: email clients that reflow quoted text, chat applications with variable-width bubbles, word processors, social media posts, and any web page that does not wrap the art in a pre or code element with a monospace stack. Trailing spaces are the second killer — some editors and form fields strip them on paste, which shears the right edge off glyphs that depend on trailing blanks. If a banner arrives broken, check the font first and trailing whitespace second; those two explain nearly every case.
Text banners versus image conversion
Search results mix two unrelated tools under one name, so it is worth being precise. A FIGlet generator starts from characters you type and produces larger characters — the input and the output are both text, and nothing is interpreted. An image converter starts from pixels and maps brightness to character density, so a photograph becomes a mosaic of @ signs and dots. They share a name and nothing else. If your goal is a logo from a PNG, you want the converter. If your goal is the word DEPLOY in six-inch letters across a terminal, you want this tool. Judging one by the other's standard is how people conclude ASCII art does not work, when they simply opened the wrong kind.
Copy, paste, and keep it working
Keep the input under eighty characters, and under twenty for the wide novelty fonts. Generate at the width of the narrowest place the banner will appear — a banner built for a wide monitor and pasted into an eighty-column terminal wraps mid-glyph and is worse than no banner. Prefer the compact spacing option when the target is small; it trades some airiness for fitting on phones and narrow panes. When embedding in code, put the art inside a block comment so no linter reformats it, and be aware that some formatters strip trailing whitespace on save, which shears glyphs — a .editorconfig entry preserving trailing spaces in that file is the durable fix. For shell startup files, generate once, paste the result as a heredoc or an echo block, and never regenerate at login: static text prints instantly and cannot fail when a dependency updates.