ASCII Art From Image

Someone in the group chat just posted their cat. Not a photo of the cat — the cat rendered entirely in punctuation, a stretch of colons and ampersands and @ signs that, squinted at from arm's length, is unmistakably the animal. Half the chat asks how. The other half has already uploaded their own faces to find out. This is the loop ASCII art has been running since the 1980s, and it has still not gotten old.

There is a serious tool underneath the joke, though. The conversion — brightness in, character density out — is the same idea that carried newspaper photographs for a century of halftone printing, and it still earns its keep in places photos cannot go: terminal splash screens, code comments, README badges, plain-text email, anywhere an image is not welcome but characters are. The rendering is primitive by design, and that constraint is the aesthetic.

This converter does the classic job with real controls: output width, density ramp, contrast, color, and inversion for light backgrounds. Drop an image in, get characters out, copy them anywhere text travels. All of it runs locally — the cat never leaves your machine on its way to becoming punctuation.

1. 1

   Load the image

   Any JPG, PNG, or WebP. Subjects with strong light-dark structure — silhouettes, high-contrast portraits, logos — convert dramatically better than flat, evenly-lit scenes.

2. 2

   Set the output width

   Start at 80 characters. The height follows automatically from the image's aspect ratio and the character cell's taller-than-wide geometry — you will see the final line count before converting.

3. 3

   Tune ramp and contrast

   Pick a density ramp — the ten-character classic or the finer seventy-step version — and adjust contrast to pull the subject out of muddy midtones. Faces usually need a contrast boost; logos often need none.

4. 4

   Convert, then copy or download

   The output renders on the page as monospace text with the exact characters you will paste elsewhere. Copy it raw, download it as a .txt file, or grab the colored version for platforms that support styled text.

The engine's core is one computation: how bright is this pixel, as a single number? The formula comes from how eyes actually weigh color — roughly 21 percent red, 72 percent green, and 7 percent blue, the coefficients standardized in the sRGB and BT.709 specifications. Green dominates because human vision does; a pure green pixel reads brighter to you than an equally intense blue one, and the formula honors that.

There is a subtlety most converters ignore, and it is worth understanding because it explains why different tools give different results from the same photo. The 21/72/7 weighting is defined on linear light, but image files store gamma-encoded values — a perceptual compression that makes dark values finer-grained. The rigorous pipeline converts each channel to linear light first, then applies the coefficients. The fast pipeline applies them directly to the stored values. The rigorous path is what this tool runs; the difference is not cosmetic — for one commonly used blue, the naive shortcut reports a brightness of 123 where the correct value is 60, nearly double, and that error decides whether a pixel becomes an = or a :.

The ramp maps that brightness number to a glyph. A ramp is simply characters ordered by ink density — the fraction of the character cell they darken. Space is zero. A period is a speck. An at sign is nearly solid. The ten-character classic ' .:-=+*#%@' spans the whole range in ten steps; Paul Bourke's seventy-character version grades it far more finely, holding recognizable detail at larger output sizes. Which to use is a resolution decision: ten steps at width 80 reads cleanly; seventy steps at width 200 rewards the zoom-in.

The last piece is geometry. Characters are taller than they are wide — a typical monospace cell runs about 1:2 — so sampling the image on a square grid produces vertically stretched output. The converter samples rows at twice the column interval, pre-compressing vertically so the characters stretch it back. It is the quiet reason this tool's output looks like the photo and other converters' output looks like the photo reflected in a funhouse mirror.

Walk the numbers for one pixel and the whole machine becomes visible. Source image 640×400. Output width 80 characters. Column step: 640 ÷ 80 = 8 pixels. Row step: twice that, 16 pixels. Output height: 400 ÷ 16 = 25 lines. So the final art is 80 characters wide and 25 lines tall — 2,000 characters standing in for 256,000 pixels.

Now one sample: a sky-colored pixel, RGB (59, 130, 246). Linearizing each channel and applying the 21/72/7 coefficients gives a luminance of about 60 on the 0–255 scale. The ramp index is 60 ÷ 255 × 9 ≈ 2.1, which rounds to ramp position 2. In ' .:-=+*#%@', position 2 is the colon. This pixel becomes a ':'. Its neighbor, a lighter cloud pixel at RGB (214, 232, 253), computes to luminance 211 — ramp index 7.5, rounding to 8, the percent sign — a much denser character, correctly signaling that on a dark-background render, this bright pixel needs heavy ink.

That table is the tool's entire soul in four rows. Every conversion you run here is this computation repeated thousands of times, with the sampling grid handling scale and the ramp handling taste. No neural network, no magic — arithmetic, applied with respect for how both eyes and fonts work.

The brightness-to-density idea is older than computers. Newspaper halftones, from the 1880s on, photographed images through a screen so continuous tones became a grid of ink dots — varying size, fixed spacing — at roughly 65 to 133 lines per inch. ASCII conversion is the same trade run in characters: fixed grid of cells, varying ink per cell, viewed from far enough away that the grid disappears. Both technologies live or die on the same property of the source: tonal range.

That is why flat scenes fail. A wall of identical midtone characters is not a rendering bug — it is a quantizer honestly reporting that the input occupied one brightness band. On the ten-character ramp, each step spans about 25.5 luminance points, so a smoothly lit sky drifting from 96 to 160 crosses only three ramp positions. The gradient exists; the ruler is too coarse to see it move:

The right-hand column is the classical repair: error diffusion — Floyd and Steinberg's algorithm, which pushes each pixel's quantization error to its unvisited neighbors in shares of 7/16, 3/16, 5/16, and 1/16, so flat tones become deliberate character mixtures whose average ink density matches the original. Newspapers reached the same effect optically. For a converter, the tool-side answers are the finer seventy-step ramp, which shrinks each step to under four luminance points, and the contrast control, which stretches a narrow band across more of the ramp — different mechanics, same goal: give the quantizer room to move.

The practical hierarchy for a flat source, in order of effectiveness: re-source with directional light, because the camera can capture what the ramp cannot invent; raise contrast to spread the band; switch to the seventy-step ramp for finer steps; and accept that studio-flat scenes will always render as texture rather than image. The halftone operators knew this too — their retouching desks existed to add tonal separation that the screen would otherwise flatten away.

The same machine, pointed at three different homes for its output, produces three very different configurations. The line-count arithmetic is worth showing because it is the whole sizing decision in one division: column step = source width ÷ output width, row step = twice that, and lines = source height ÷ row step.

The chat version is small because chats wrap: sixty characters survives every mainstream messenger without folding a line, and the ten-step ramp keeps the subject readable at phone font sizes. The README version is the most constrained of the three — eight hundred characters fits comfortably inside a code comment, the binary ramp guarantees the logo reads at a glance, and inversion matters because most documentation renders on white.

The splash version earns its size. A hundred and sixty characters fills a default terminal exactly, the seventy-step ramp holds detail the ten-step version flattens, and 7,200 characters is still a text file measured in kilobytes rather than the megabytes of the PNG it replaces. Same tool, same arithmetic, three registers of output — the settings are the art direction.

The medium has hard limits, and pretending otherwise wastes an afternoon. The known failure modes:

• Flat lighting. Evenly-lit scenes produce seas of identical midtone characters — a page of = signs with no image inside. High-contrast sources convert; studio-flat ones do not. The contrast slider helps; it cannot perform miracles.
• Fine detail. Eyelashes, text in the scene, texture — none of it survives an 8-pixel sampling step. Design for the medium: bold shapes, clear silhouettes, dramatic lighting.
• Proportional fonts. Pasting into a proportional-font context reflows every line by character width and destroys the image. Monospace or nothing.
• Dark backgrounds without inversion. Light-on-dark terminals invert the meaning of density — bright pixels need dense characters there. If the output looks like a negative, flip the invert toggle.
• Line wrapping. Output wider than the container wraps mid-line, shearing the image into staggered fragments. Match width to destination: 80 for code contexts, less for chat.
• Very large outputs. Past roughly 200 characters wide, viewers scroll rather than step back, and the illusion collapses. ASCII art is a glance medium, not an inspection medium.

Source selection does more for the result than any slider, and the pattern is consistent enough to tabulate. Six subject types, honestly rated:

The pattern underneath the table: the converter describes brightness ranges, so subjects built from brightness ranges — silhouette against sky, face against shadow — carry their own contrast with them. Subjects whose interest lives at scales finer than the sampling step, or whose lighting erases tonal separation, fight the medium instead of feeding it. Choosing the source is the strongest control on the page.

More people than the retro framing suggests:

• Developers — terminal splash screens, CLI tool banners, README flourishes, log easter eggs
• Chat dwellers — profile-picture pranks, reaction-art, the eternal cat conversion
• Newsletter and plain-text email writers — the only imagery plain text can carry
• Sysadmins and terminal dwellers — decorating the tools that never left the command line
• Retro computing enthusiasts — banners for BBS revival nights and demoscene threads
• Teachers — a genuinely memorable demonstration of brightness quantization and sampling

The teacher entry is less eccentric than it looks. ASCII conversion compresses half an imaging curriculum — sampling, quantization, gamma, luminance weighting — into a five-minute demonstration with a punchline students can paste into their own chats. Several of the technical sections above exist because those students keep asking the follow-up questions.

The ramp is the tool's most consequential setting, and the choice is a real trade rather than a style toggle:

The binary ramp deserves a defense: mapping to just two characters, space and at-sign, turns any photo into a high-contrast stencil that reads instantly even at small sizes. It is the least respected option on the list and often the most effective for logos and silhouettes. Between the extremes, the ten-step classic remains the default because it degrades gracefully — paste it into a chat and it still reads as the subject, where the seventy-step version needs its space and its font to survive the trip.

A related decision is ASCII versus its Unicode successors — block elements like ▓ and ░, or eight-dot Braille characters packing 2×4 dots per cell. Those encodings carry far more detail per character and produce stunning terminal art. They also break every plain-text context that predates them, which is precisely the portability ASCII was chosen for in the first place. This tool speaks classic ASCII; the Unicode variants are a different medium with different rules.

The conversion pipeline is entirely local: your browser decodes the image, the sampling and luminance math run in the page, and the output is text generated in the same tab. There is no upload, because there is no server that could receive one — the tool is arithmetic plus typography, and neither needs a datacenter.

That buys the usual privacy — the group-chat cat, the team photo, whatever passes through stays put — plus something rarer in image tools: offline reliability. The conversion works identically on a plane, behind a firewall, or with the network disabled, because every stage of it is local computation. The characters you copy were computed on your hardware, from your pixels, in your tab. Somewhere, the original ASCII artists of the 1980s would find that arrangement entirely fitting.

Three neighbors share the spirit of this one:

• Image Color Extractor — the palette question the brightness question keeps leading into
• Image to Text Converter (OCR) — the other image-to-text direction: extracting the words already inside an image
• Placeholder Image Generator — the utilitarian sibling, generating labeled stand-in images when you need structure, not art

The trio covers the image-to-text family: art here, words in OCR, and scaffolding in placeholders. Confusing them is a rite of passage — every one of these tools has received at least one support message from someone who needed its sibling instead.