How to make ASCII art that still reads

Choose generation, command line or drawing by hand.

A browser image converter is the fastest path when you have a source image and want editable text immediately. It lets you preview width, density and background without installing anything. This is a strong fit for README art, chat posts, terminal banners and quick graphic experiments.

A command-line tool is better when the conversion must be repeatable: processing a folder, using the same dimensions in a build script, or piping output into another program. The trade-off is setup and a less visual adjustment loop. Drawing by hand is slowest but gives you full control over outlines, expressions, lettering and intentional exaggeration. Many polished pieces start with a conversion and finish with manual edits in a monospaced editor.

Prepare the image for reduction.

ASCII has far fewer cells than a photograph has pixels. Small details disappear first, so crop around one clear subject and remove empty margins. A subject separated from its background usually converts better than a busy scene with many equally important objects.

1. Crop for silhouette. Make the outline readable at thumbnail size before thinking about characters.
2. Check tonal separation. If subject and background share the same brightness, increase contrast or simplify the background first.
3. Decide on light or dark. Dense characters normally represent shadows on a light canvas; terminal mode reverses that relationship for light marks on black.
4. Test grayscale mentally. Color differences alone do not help a monochrome ramp. Use the color ASCII converter when color is essential to recognition.

Choose characters by visual weight.

A character ramp is an ordered sequence from low ink coverage to high ink coverage. A short ramp such as .:+#@ creates bold, poster-like regions. A longer ramp preserves more tonal steps but can make the result noisy, especially at small widths.

  .::
 :+##+:
:+#@@#+:
  +##+

  .'`^",:;
 ;Il!i><~+
 1tfLCG08@
  :+xLC:

Use characters from the same monospaced font you expect at the destination. Glyph weight changes between fonts, and ambiguous-width Unicode symbols may take two terminal columns. Plain ASCII characters are the safest choice when exact alignment must survive copy and paste.

Set width for the destination, not the source.

Width is the most influential control. More columns retain detail but produce longer lines that wrap in chats and narrow code blocks. Start around 60–80 characters for a README or desktop terminal, then test in the actual container. Use 40–60 for compact posts. Go wider only when the final surface can preserve monospaced lines without wrapping.

Text cells are usually taller than they are wide. If you convert pixel dimensions directly, faces and circles look vertically stretched. Compensate by reducing the number of output rows relative to columns. Pic to ASCII applies a character-cell correction automatically, but a hand-built workflow should treat this as a required geometry step.

Optimize the character matrix after conversion.

Treat generated output as a draft. Remove isolated marks in empty areas, reinforce the subject outline, and simplify patches where neighboring tones flicker between too many characters. For faces, preserve the eyes, nose line and outer contour before subtle shading. For logos, sacrifice gradients to keep letterforms and negative space intact.

• Paste into a monospaced code block and look for wrapped lines.
• Compare light and dark backgrounds before choosing inversion.
• Delete trailing spaces if the destination strips them.
• Keep every row the expected width when alignment is critical.
• Save a plain-text master before styling a colored HTML version.

The final test is recognition at normal reading distance. If the art only works when you compare it side by side with the source, reduce detail and strengthen the large shapes.