ASCII art generator

How a picture becomes text

The image is shrunk to exactly one pixel per character — 100 columns means a hundred pixels across — and each pixel is asked one question: how dark is it? The answer picks a character from a list ordered from empty to solid, a space at one end and something like @ at the other. Dark areas get the characters that put ink on the page, light areas get sparse ones, and at arm’s length your eye reassembles the result.

Two details matter more than they sound. Brightness is a weighted sum rather than a flat average of red, green and blue, because the eye is far more sensitive to green; average them evenly and a blue sky comes out as bright as a lawn. And each cell has to be the average of every pixel inside it, not one sample, or the art crawls with speckle as you drag the width.

Why the height is halved, and what it looks like when it is not

A character cell is not square. In every monospace font it is about twice as tall as it is wide: the glyph advances roughly six tenths of its point size across, then sits on a line about one and two tenths deep. A grid of 100 by 100 characters is therefore a portrait.

The fix is to ask for half as many rows as the arithmetic first suggests, and it is applied here. Skip it and a logo comes out as a tall oval, which is the commonest fault in hand-written converters. The preview has the same problem one level up, so this page measures the monospace font your browser chose and sets the line spacing to match it. Paste the art somewhere with generous leading and it stretches again.

Fewer characters usually reads better

The famous ramp has seventy characters in it, ordered by how much of the cell each fills. Its steps are uneven, several neighbours are indistinguishable at any size, and the order was worked out for one typeface, so on a gradient it bands in odd places.

Ten characters give you ten clean tones, and ten is plenty — a picture that reads at all carries its subject in its shapes, not its shading. Reach for the long ramp only when the source is large, smooth and high in contrast. The shaded blocks are the most legible at small sizes, each being a real percentage of coverage rather than a glyph that looks dense; they want tight leading to tile without gaps. They are not ASCII, though: Unicode block characters, fine in a README or a UTF-8 terminal and wrong anywhere that literally means seven-bit text.

Where ASCII art still earns its place

It survives because text goes where pictures cannot. A README renders a logo in any terminal that can cat the file, with no image host to rot. Command-line tools print banners the same way, and commit messages, release notes and plain-text signatures all take art a screenshot would be stripped from. The medium in each case is text and always will be.

What converts well, and what does not

High contrast and one clear subject. A logo, a silhouette, a face lit from one side, a black-and-white photograph: these come back recognisable at 80 columns. Busy photographs do not. A group shot or a landscape spreads its detail evenly, a hundred columns cannot hold that much, and out comes grey texture with no picture in it.

If a source is close but muddy, crop hard to the subject and push the contrast up until the background has gone to empty space; losing it usually helps, because the silhouette carries the image at this resolution. Flat vector artwork is the easiest source of all — rasterise it first, since this tool reads bitmaps only, and the SVG converter does that in the same tab.

Why nothing is uploaded

The image is decoded by the browser, drawn into a small canvas, and read back as pixels in this tab. There is no server in that path, no queue, and no copy of your picture on a stranger’s disk. Turn the network off and it still works.