ASCII Art: How Character Ramps Turn Brightness Into Text

Every ASCII art generator rests on one idea: a printed character covers a certain proportion of its cell with ink, so a row of characters can behave like a row of grey values. Order your characters from empty to dense and you have a greyscale palette made of punctuation. The ASCII Art Generator exposes that palette directly, which means understanding the mapping is the difference between a smudge and a portrait.

A format older than the computers that made it famous

Making pictures out of letterforms predates digital displays entirely - typewriter artists were building images from overstruck characters long before anyone had a screen to put them on. When line printers arrived, computer labs discovered they had a device that could only produce characters and therefore had to draw with them, and printed character portraits became a standard piece of machine-room folklore.

The ASCII standard itself was published in 1963, and the art form took its name from the character set that finally made it portable between machines. Its second life came with dial-up bulletin boards, Usenet and IRC, where bandwidth was scarce and text was the only thing guaranteed to render the same way everywhere - which is why email signatures, README headers and login banners were once full of it. The tradition never really stopped: entire animated films have been rendered as ASCII and served over plain telnet connections, and terminal image viewers still use exactly the technique described below.

How the mapping works

The conversion has three steps. First the image is scaled down to the number of character columns you asked for, because one character will represent one whole region of the original. Then each remaining pixel is reduced to a single brightness number. Finally that number is used as an index into your character ramp: dark values pick characters from one end, bright values from the other.

The tool's default ramp runs from a space through .:-=+*#%@ to the at sign, ordered by how much of the cell each glyph fills. Brightness is measured as a straight average of the red, green and blue values, which is fast and predictable. It is worth knowing that this differs from perceptual luminance, where green counts for far more than blue - the difference is explained in the piece on reading an image histogram. In practice it means strongly coloured areas can land on a lighter or heavier character than your eye would expect, and a black and white source therefore converts more predictably than a saturated one.

Why the output is squashed, and how it is fixed

Character cells are not square. In almost every monospaced font a character is roughly twice as tall as it is wide, so treating one character as one pixel would stretch your image vertically by a factor of two. Generators correct for this by sampling fewer rows than columns; this one multiplies the row count by a little over half, which is close to the proportions of common terminal fonts. If your output still looks slightly tall or wide, the font you pasted it into has different cell proportions than the one it was tuned for.

Choosing a ramp

• Long ramps of fifty or more characters give the smoothest gradients and are the traditional choice for detailed portraits. They also expose font differences most clearly, because subtle steps in density depend on how your specific font draws each glyph.
• Short ramps of five to ten characters posterise the image into distinct bands. This usually reads better on screen than a long ramp, especially at small column counts.
• Two-character ramps such as a space and a hash produce pure silhouettes, which work beautifully for logos and high-contrast subjects.
• Block characters from the wider Unicode set give near-continuous shading and are what modern terminal image viewers use. They are no longer strictly ASCII, so they can break in older software, but they look dramatically smoother.

Whatever ramp you choose, the ordering must go monotonically from least ink to most. A ramp with a heavy character in the middle produces bright speckles scattered through dark regions.

Getting a good result from a photograph

The character density slider sets how many columns you get, and more is not automatically better. A width of 60 to 100 characters is the sweet spot for something to be pasted into a chat message, a code comment or a README, and it echoes the classic terminal width that a great deal of software still assumes. Very high densities produce output that wraps and collapses in anything but a full screen editor.

Because so much information is discarded, the source matters more than the settings. Crop tight so the subject fills the frame, prefer strong silhouettes and simple backgrounds, and increase contrast before converting - a flat, hazy photograph turns into a flat, uniform block of the same three characters. These are the same constraints that govern converting a photo to pixel art, where blocks of colour replace glyphs but the reduction problem is identical.

Pasting it somewhere useful

ASCII art only holds together in a monospaced font. Paste it into a document set in a proportional typeface and every line becomes a different length. Save the output as a text file, or paste it inside a code block, a <pre> element or anywhere the font is already fixed width. Watch out for editors that convert runs of spaces into tabs, and for chat clients that collapse consecutive spaces - both destroy the alignment silently.

The whole conversion happens on a canvas in your own browser, so a portrait, a company logo or an unreleased design can be turned into text without ever being uploaded.