How Images Become Text
The simple idea behind ASCII art — brightness in, characters out — and how to make yours actually look good.
A picture made of letters
ASCII art is one of the oldest forms of digital creativity — pictures drawn entirely from the characters on a keyboard. It predates the web, born in the era of teletype machines and dot-matrix printers that could only output text, and it has survived because it works anywhere text goes: a code comment, a terminal, a README, a plain-text email, a forum post. TheASCII Art Generatorturns any image you have into this timeless format automatically.
The core trick: brightness to characters
The whole idea rests on a simple observation: different characters have different visual "weight". A @ or a # fills a lot of its cell with ink and reads as dark; a . or a space reads as light. If you line up characters from heaviest to lightest — say @ % # * + = - : . (space) — you have a scale of brightness made of text. Converting an image is then just a matter of matching each part of the picture to the character with the right weight.
In practice the generator does three things. First it shrinks your image to a small grid — one cell per character — because a character is far bigger than a pixel. Then, for each cell, it measures the brightness (a weighted average of red, green and blue). Finally it maps that brightness onto the character ramp: dark cells get dense characters, bright cells get light ones. Read the grid of characters from a distance and your eye reassembles the original image.
Why characters are taller than they are wide
There is one subtlety that separates good ASCII art from squashed-looking output: character aspect ratio. Monospace characters are typically about twice as tall as they are wide. If you used one character per pixel-cell naively, the picture would come out stretched vertically. So a good converter uses roughly half as many rows as it would columns for a given image shape, squashing the grid to compensate for tall characters. That correction is why the output keeps the proportions of the original rather than looking elongated.
Choosing the right image
ASCII art has far less resolution than a photo, so the image has to survive being reduced to a coarse grid of brightness values. That means contrast and a clear subject matter enormously.
| Works well | Works poorly |
|---|---|
| Logos & silhouettes | Busy, cluttered scenes |
| Portraits on a plain background | Low-contrast, hazy photos |
| Bold, high-contrast subjects | Fine detail & small text |
Two controls help you dial it in. Width sets the level of detail — wider means more characters and finer detail, but a bigger result that may not fit everywhere. Invert flips the ramp, which you need depending on whether the art will sit on a dark background (light characters on dark) or a light one. If a first attempt looks muddy, try a higher-contrast crop or increase the width.
Where to use it
- README banners: a project logo in ASCII at the top of a README or in a CLI's
--helpoutput. - Terminal splash screens: shown when a program or shell starts.
- Code comments: a small marker or logo in a source file.
- Plain-text messages: signatures, forum posts, and anywhere images aren't allowed.
Wherever it lands, remember the golden rule: paste it into a monospace context. ASCII art depends on every character being the same width so the columns line up; in a proportional font the grid drifts and the picture warps.
A tiny piece of internet history
Choosing a character ramp
The ramp — the ordered set of characters from darkest to lightest — is the single biggest influence on how your art looks. A longer ramp gives more tonal steps and therefore smoother gradients; a shorter one produces a punchy, high-contrast, posterised look. Neither is better; they suit different images.
| Ramp | Character | Best for |
|---|---|---|
| Detailed | Many steps, smooth | Portraits, photos with gradients |
| Simple | Few steps, bold | Logos, silhouettes, small output |
| Blocks | Solid fills | A pixel-art look; terminals |
The block ramp deserves a special mention because it is technically no longer ASCII at all — █ ▓ ▒ ░ are Unicode block-drawing characters. They give far more even coverage than letters do, which produces a cleaner, more image-like result, at the cost of only working where those characters render. If your output looks patchy with letters, switching to blocks usually fixes it instantly.
Why brightness, not colour
The conversion measures each cell's luminance — perceived brightness — rather than treating red, green and blue equally. The standard weighting is roughly 30% red, 59% green and 11% blue, because human eyes are far more sensitive to green light than to blue. A pure green and a pure blue of the same numeric intensity look wildly different in brightness to us, and averaging the channels naively would make blue areas far too light.
That weighting is why a red logo on a blue background can convert beautifully even though both are "mid-brightness" numerically, and it is the same maths used when converting a photo to greyscale properly. It also explains the fundamental limitation of the medium: since only brightness survives, two different colours with the same brightness become the same character. An image whose subject is distinguished from its background purely by hue — a red apple on a green cloth of similar tone — will vanish into noise. Converting your image to greyscale mentally is a good way to predict whether it will work.
Preparing an image that converts well
- Crop tight. The subject should fill the frame; ASCII has too little resolution to spare on background.
- Raise contrast first. Editing the image to boost contrast before converting produces a far crisper result than any ramp choice.
- Simplify the background. A plain or blown-out background separates the subject cleanly; a busy one competes with it.
- Check it in greyscale. If the subject disappears when you remove colour, it will disappear in ASCII too.
- Try inverting. A dark subject on light may read better inverted, especially for terminal use.
Width is the last dial to touch, and the temptation is always to crank it up. Resist a little: very wide art wraps badly in most contexts and stops reading as an image when the viewer cannot see it all at once. For a README banner, 60–100 characters is usually right; for a full-screen terminal piece you can go wider.
A folk art with real history
Text-based images predate computers entirely — typewriter artists were composing pictures from letters in the late 1800s, and the practice continued into the era of teletypes and line printers, where a printed ASCII portrait was a common piece of computer-room decoration. When bulletin board systems and Usenet arrived, ASCII art became the internet's native visual language simply because images could not be displayed at all.
That period produced genuine conventions and communities. FIGlet, released in 1991, turned words into large block letters and is still used for CLI banners today. Email signature art, elaborate hand-drawn scenes shared on Usenet, and the whole "ANSI art" scene of coloured BBS screens all grew from the same constraint. Related traditions appeared elsewhere too — Japanese shift_JIS art built far more detailed figures using a wider character set, and its descendants still circulate as text emoticons.
Where it still earns its place
ASCII art survives because text goes places images cannot. A CLI tool can print a logo on startup or in its help output with no dependencies and no graphics support. A README banner renders identically on every platform and in every git client. Server login banners and build-system output use it to make status instantly recognisable. And in any plain-text context — a commit message, a code comment, a terminal-only environment — it is the only illustration available.
There is also an accessibility caveat worth respecting: screen readers will attempt to read ASCII art character by character, producing meaningless noise. If you publish it on a web page, wrap it so assistive technology can skip it and provide a short text description instead. Used thoughtfully, it is a charming, zero-dependency way to add personality to places that have no other way to show an image.
Troubleshooting your output
If a conversion disappoints, the fix is usually one of a handful of adjustments rather than a different image.
| Problem | Fix |
|---|---|
| Looks like grey mush | Raise contrast in the source image; crop tighter |
| Subject blends into background | The two have similar brightness — recrop or edit |
| Too dark overall | Toggle invert, or lighten the image first |
| Stretched or squashed | Being viewed in a proportional font — use monospace |
| Detail lost entirely | Increase width, or accept a bolder, simpler ramp |
The single highest-impact adjustment is almost always contrast in the source image. Because the conversion collapses everything to a handful of brightness levels, an image whose tones cluster in the middle produces characters that all look similar. Pushing the darks darker and the lights lighter before converting spreads those values across the full ramp — and it routinely turns an unrecognisable result into a sharp one without changing any tool setting.
Pasting it without breaking it
Getting ASCII art out of a tool and into its destination intact requires a little care. Wrap it in a code block or <pre> element so the whitespace and line breaks survive — most editors and chat apps otherwise collapse consecutive spaces, which destroys the image. In Markdown, indent by four spaces or use triple backticks. Watch out for platforms that auto-format or "smarten" characters, and for anywhere with a line-length limit that will wrap your rows. If the art looks like noise after pasting, the cause is almost always a proportional font or collapsed whitespace rather than a bad conversion.
Beyond still images
The same brightness-to-character mapping extends naturally to moving pictures. Run it on every frame of a video and you get ASCII video — a genre with a genuine cult following, most famously the fan-made ASCII rendition of Star Wars that has been served over telnet for decades. Some terminal media players will happily render a video as text in your console using exactly the technique described here, just applied sixty times a second.
There are richer variants too. ANSI art adds colour escape codes, so each character carries a foreground and background colour as well as a shape — dramatically increasing the effective detail, which is why BBS-era ANSI screens look so much more like real images than plain ASCII. And "coloured ASCII" on the web works the same way, wrapping each character in markup with its own colour. The trade-off is always portability: the plainer the output, the more places it will render correctly. Plain monochrome ASCII remains the most universal, which is why it is still the default for anything that has to work everywhere.
It is a medium with real constraints, and working with them rather than against them is what produces output people actually recognise. In short: pick a high-contrast image, choose a ramp that suits it, set a width that fits where it is going, and always display the result in a monospace context. Get those four right and almost any picture converts into something recognisable. Beyond its practical uses, ASCII art is a genuine folk art of computing. Whole communities built elaborate multi-thousand-character scenes by hand, "figlet" tools turned words into big block letters, and every bulletin board and early website had its share. Generating it from an image is the modern, instant version of a craft people once did character by character — and it is oddly satisfying to watch a photo resolve into a mosaic of symbols. Drop an image into theASCII Art Generator, tune the width and character set, and copy your text art wherever you need it — all rendered privately in your browser.