The banner that fell apart
You type your project name, hit convert, and a fat block-letter banner fills the box. It looks sharp right there. Then you paste it into your README on GitHub and the letters shear into diagonal nonsense, the "M" leans through the "E," and the whole thing reads like a ransom note that lost interest halfway. The art is fine. The font it landed in is not.
ASCII art survives in exactly one environment: a monospace font, where every character occupies the same horizontal width. Hold onto that single constraint and this tool becomes dependable. Ignore it and you will keep producing broken banners and blaming the generator for your display's sins.
What the tool builds
Type a short word or phrase and it renders each character as a small grid of block characters, stacking rows so the word reads left to right. The output is plain text. There are no images, no special encoding, nothing that needs a plugin to view. Copy it, paste it anywhere text goes, and the banner travels with it.
The letters are built from solid Unicode block characters, either a filled block or a lighter shaded version, arranged so that a glyph five rows tall and five columns wide reads as that letter once you step back a little; the glyphs are separated by a single space. Because it is only text, it lives happily in a code comment, a terminal window, a plaintext email, or the top of a Markdown file.
The monospace rule
In a proportional font an "i" is skinny and a "w" is wide. Block art assumes every cell is identical, so the moment a proportional font renders it, the columns drift apart and the letterforms collapse into noise. Monospace fonts, the kind in code editors and terminals, keep every glyph the same width. That even grid is the only ground this art stands on.
| Renders correctly | Renders as garbage |
|---|---|
| Code editors and terminals | Word or Google Docs body text |
| GitHub README inside a code block | A proportional-font web page |
| Terminal motd and startup scripts | Email clients in their default font |
| Inside triple-backtick fences | Slack or Discord messages |
The fix on the web is nearly always the same move: wrap the banner in a fenced code block so the renderer switches to monospace before it paints your letters.
Keep your input short
Block letters are wide. A single character can span four or five columns, so an eight-letter word easily runs past forty columns, and a full sentence blows straight through the 80-character width that most terminals and code windows still treat as comfortable. When output exceeds the display width it wraps mid-letter, and your banner turns into unreadable confetti.
The discipline is to feed the tool a word or a very short phrase, never a headline. "API" is perfect. "ACME" is fine. "Welcome to our platform" is not, and no amount of resizing rescues a sentence forced into block art. If you need a tagline, set the name large and put the tagline in ordinary text underneath.
Check the width before you commit. The line counter reports your longest line, which tells you exactly how wide your longest rendered row is, and if it creeps past roughly 78 characters, shorten the input or accept that it will wrap on someone else's screen.
Where banners earn their place
README headers. A project name in block letters at the top of a GitHub README signals care and gives the page a face. Inside a code fence it renders identically for every visitor, on every screen.
Program startup and terminal motd. Command-line tools and servers often print a banner on launch, and the message-of-the-day file on a Unix box is the classic home for one. Block art survives there because terminals are monospace by definition.
Plaintext newsletters. Some newsletters and old-school mailing lists stay deliberately plaintext. A small banner is the only decoration available, and it passes through systems that strip images entirely.
Code comment headers. A file-level comment with the module name in letters is a recognizable convention in some shops. Read the etiquette note below before you adopt it team-wide.
Copy-paste etiquette in code comments
Big headers in source files are loved and loathed in equal measure, and the dividing line is restraint. One short banner at the very top of a file helps humans orient themselves in a large codebase. A banner above every function is noise that shoves real code off the screen.
One practical caution: block characters are multi-byte in UTF-8, so a banner can quietly upset tools that count bytes rather than characters, and a few older systems still choke on anything outside plain ASCII. If your output must stay strictly seven-bit, this tool cannot produce it: both of its fonts draw with Unicode block characters, so you would need a different tool. When you need to move text into or out of encoded numeric form, the ASCII to text converter is the companion tool that handles the other direction.
Frequently Asked Questions
Why does my banner look broken after I paste it?
Almost always because the destination uses a proportional font. Block art needs monospace, where every character is the same width. Wrap it in a code block or code fence, or paste it into a terminal or editor, and it snaps back into shape.
How do I stop the art from wrapping?
Shorten your input. Block letters are several columns wide each, so long words exceed the display width and wrap mid-letter. Stick to one short word or a brief phrase, and check the widest row with the line counter and its "Longest line" figure before you paste it anywhere.
Is the output real ASCII?
No. Both fonts draw with Unicode block characters, so the output is always multi-byte and never strict seven-bit ASCII. People call it "ASCII art" only out of long habit, not because of its encoding. A system that requires pure seven-bit ASCII cannot use this output at all, so you would need a different tool to produce it.
Can I use a banner in a GitHub README?
Yes, and it is one of the best uses there is. Put it inside a fenced code block, three backticks on either side, so GitHub renders it in monospace. Without the fence, the proportional default font will distort your letters.
Does it handle lowercase and numbers?
The fonts render whatever they support, typically uppercase letters, digits, and a handful of symbols. Uppercase reads best at this scale. Lowercase input is uppercased automatically before rendering, so it produces exactly the same banner and needs no separate conversion step.
Set the name large, keep everything else small
The habit that separates a good banner from a broken one is scope. Give the tool a single short word, wrap the result in a monospace context, and let ordinary text carry the rest. Block art is a nameplate, not a paragraph. Treat it that way and it looks deliberate every time; ask it to hold a sentence and it falls apart in front of an audience.