ASCII Art Generator: Two Modes, One Plain-Text Promise

Two modes that both produce the same kind of output — plain, monospaced text art — from two completely different inputs. Text Banner turns a typed word or phrase into large block letters built out of ASCII characters. Image to ASCII turns an actual photo or graphic into a grid of characters whose density approximates the image's light and dark areas. They share an output format and almost nothing else underneath.

Block letters are a font problem, not a text problem

Rendering a letter as a large ASCII block shape means having a pre-defined pattern for every character the banner mode supports — a grid template describing which cells are "on" and "off" for each letter at the chosen scale. This is essentially maintaining a tiny bitmap font, by hand, in a format built out of the fill character rather than actual pixels. Getting letters to look proportional and legible next to each other, especially narrow ones like "I" next to wide ones like "M," needed real attention to spacing between characters rather than just concatenating each letter's fixed-width block pattern edge to edge, which produces a cramped, uneven-looking result.

Image-to-ASCII is a density-mapping problem

Converting an image means sampling brightness across a grid of regions in the source image, then mapping each region's brightness to a character whose visual density roughly matches it — a mostly-empty space character for bright areas, a dense character like "@" or "#" for dark ones, with a gradient of characters in between for the mid-tones. Choosing that character gradient carefully mattered more than I expected: too few density steps and the output looks harshly posterized, with visible banding between brightness levels; too many and mid-tones become inconsistent across different monospace fonts, since not every font renders every character at a visually consistent density relative to the others.

The invert toggle exists because source images vary wildly

A dark-background, light-subject photo and a light-background, dark-subject one need opposite density mappings to look correct as ASCII art — otherwise the output can come out looking like a negative of what anyone would expect, with the subject rendered as empty space and the background rendered as dense character fill. Rather than trying to automatically detect which mapping direction a given image needs, which is a genuinely hard problem to get reliably right across arbitrary images, I exposed a simple invert toggle so a person can flip the mapping themselves the moment the initial result looks backwards. A one-click manual fix beats an automatic heuristic that's right most of the time and confusingly wrong the rest of the time with no way to correct it.

Output width is a real trade-off, not just a cosmetic setting

The width options — 40, 70, 100, or 140 characters — directly trade detail against how practical the output actually is to use. A wider output captures more of the source image's detail, but it also produces a block of text wide enough to break formatting the moment it's pasted somewhere with a narrower fixed-width container, like a chat message or a code comment. A narrower output is more universally paste-safe but loses recognizable detail from anything but the simplest source images. There's no single correct default here, which is why it's an explicit choice rather than one fixed width the tool picks for you.

Monospace fonts aren't actually as uniform as the name implies

"Monospace" only guarantees every character occupies the same horizontal width — it says nothing about how visually dense or sparse each character looks at a given size, which is exactly the property image-to-ASCII depends on. A character that looks appropriately dark in one monospace font can look noticeably lighter or heavier in another, which means the density gradient tuned by eye against one font could read as subtly wrong when pasted somewhere rendering in a different one. I tuned the character gradient against a couple of the most common monospace fonts people are likely to paste this into — a terminal, a code editor, a chat client — accepting that it won't be pixel-perfect everywhere, since chasing perfect consistency across every possible monospace font a visitor might use would be chasing a target that moves depending on software entirely outside this tool's control.

Plain text output was the one non-negotiable constraint

Both modes output plain, unstyled text specifically so the result pastes cleanly into a terminal, a code comment, or a chat message — anywhere that only accepts monospaced text and nothing else. It would be technically easy to add colored output using terminal escape codes or HTML spans, and I left that out deliberately, because the entire value of ASCII art is that it works absolutely everywhere plain text works, with zero rendering requirements. Adding color support for the environments that happen to support it would mean the output silently behaves differently depending on where it's pasted, which undermines the one guarantee this tool is actually built to provide.

There's something satisfying about a tool that produces its entire visual output using nothing but the ninety-some printable characters every text medium already supports. No image hosting, no special markup, no rendering engine required on the receiving end — just characters that happen to form a recognizable shape when a monospace font lines them up correctly. That constraint is the whole reason this format has stuck around for decades, and it felt worth preserving faithfully rather than "modernizing" it with features that would break the one thing that makes it genuinely portable.

Between the two modes, I expect Text Banner to be the more immediately useful one for most visitors, and Image to ASCII to be the one people come back and play with once out of curiosity. Both are worth having either way — one solves a real, recurring small need, and the other is just genuinely fun to watch a photo turn into a grid of characters that somehow still reads as the original image, which never really stops being a little bit delightful even after building the thing myself.