How Text-to-ASCII Generators Work

Type "OK" into a banner generator like ours and you get this back in a few milliseconds:

  ___  _  __
 / _ \| |/ /
| | | | ' /
| |_| | . \
 \___/|_|\_\

It looks like magic the first time, but the machinery underneath is refreshingly simple — simple enough that the standard for it, the FIGlet font format, has barely changed since 1991 and still runs everywhere from Unix servers to the JavaScript in your browser tab. Here is how the trick works, piece by piece.

Every letter is a tiny grid of characters

An ordinary font describes letter shapes as curves. A FIGlet font describes each letter as a small rectangle of plain characters — typically five to ten rows tall and a handful of columns wide. The capital H in the classic "standard" font, for example, is stored as a six-row block built out of pipes, underscores, and spaces. There is no drawing involved at render time: the glyph is text, designed once by a human font author who decided which slashes and underscores best suggest each letterform at that size.

A font file (a .flf file, for "FIGlet font") is just a plain-text archive of these blocks: a header line with the font's dimensions and settings, then one block for each printable ASCII character, in order. Because the format is plain text, anyone can open a font in an editor, see exactly how each letter is drawn, and make their own variant. That openness is why hundreds of fonts exist — this site ships 59 of them, from tidy block capitals to sprawling script styles.

Rendering: stack rows, not letters

To render a word, the generator cannot simply print each big letter one after another, because output is written line by line. Instead it works row-wise: take row 1 of the first letter, append row 1 of the second letter, and so on across the whole word; then do the same for row 2, and repeat down to the last row. Conceptually, all the letter-grids are placed side by side and the result is read off horizontally. As long as every glyph in a font has the same height, the rows line up and the word emerges intact.

Kerning and "smushing"

Naively butting the rectangles together leaves wide gaps, because each glyph block includes padding. FIGlet defines three layout modes, and our generator exposes them in the Layout control:

• Full width — glyph blocks are placed side by side untouched. Widest output, most whitespace.
• Kerning (our "Default") — the blocks are slid toward each other until any character of one glyph would touch a character of the next, then stopped. Gaps shrink, but no characters merge.
• Smushing (our "Fitted") — the blocks are slid one step further, so the edge columns overlap, and a set of rules decides what single character should represent the two that now share a cell. For instance, two underscores merge into one underscore, a / meeting a \ can become |, and any visible character wins against a space. Each font declares which smushing rules it tolerates in its header, because font authors know which merges keep their letterforms legible.

One subtle detail: font authors sometimes need a space inside a glyph that must never be smushed away — the gap in the middle of a U, say. The format solves this with a "hardblank," a placeholder character (often $) that behaves as an immovable space during layout and is replaced by a real space at the very end.

Why monospace is non-negotiable

Everything above assumes one thing: every character occupies exactly the same width on screen. FIGlet output is a grid, and it only looks right in a monospace font, where an i, a W, and a space are all the same width. Paste a banner into a proportional font — a Word document, a default email body — and the columns drift, the diagonals shear, and the art collapses into noise. This is not a bug in the generator; it is the viewing environment breaking the grid. It is also why ASCII art thrives in terminals, code editors, and <pre> tags, all of which are monospace by convention, and why our preview panel renders in a monospace stack no matter what your system default is.

The other direction: images to characters

Image-to-ASCII conversion, the second tool on this site, shares the grid idea but inverts the process. Instead of building glyphs up from characters, it tears an image down into cells. The image is scaled to a chosen number of columns, each cell's pixels are averaged into a brightness value, and that brightness indexes into a "ramp" — a string of characters ordered from sparse to dense, such as:

 .:-=+*#%@

A bright cell becomes a space or a period; a dark cell becomes a % or @. One correction matters more than any other: character cells are taller than they are wide (roughly 2:1 in most monospace fonts), so the converter samples fewer rows than a square grid would need. Skip that adjustment and every image comes out stretched vertically. Add optional brightness, contrast, and gamma adjustments before the ramp lookup, and per-cell color sampling if you want colored output, and you have essentially the entire algorithm our image converter runs on a canvas element in your browser.

Why this all runs client-side just fine

Neither algorithm needs a server. Rendering a FIGlet banner is string concatenation over a few kilobytes of font data; converting an image is a single pass over a downscaled pixel buffer. A phone from a decade ago can do both between keystrokes. That is why generateascii.com does everything locally: the font files and figlet.js port load with the page, your text and images never leave the browser, and the preview updates live as you type. The 1991 design turned out to be perfectly shaped for the 2020s web.

If you want to see the layout modes in action, open the generator, type a word with adjacent round letters ("moon" works well), and switch between Full width, Default, and Fitted — you can watch the kerning and smushing rules pull the letters together.