Free Image to ASCII Art Converter

How It Works

1. Upload an image: Select any image (JPEG, PNG, WebP, GIF) to convert to ASCII art.
2. Adjust settings: Set the output width in characters, choose the character density set (detailed or minimal), and toggle between color and monochrome.
3. Copy or download the ASCII art: Copy the text output or download it as a text file to share or embed.

Why Use Image to ASCII Art Converter?

ASCII art converts photographic images into text characters, a technique that ranges from nostalgic computing aesthetics to modern creative expression in terminal applications, README files, emails, comments, and social media. The Image to ASCII converter automates the complex brightness-to-character mapping and delivers shareable text art from any photo instantly.

Features

• Adjustable width: Control the number of columns to balance detail and readability.
• Multiple character sets: Use dense character ramps for detailed shading or minimal sets for bold graphic results.
• Color ASCII mode: Generate ANSI color codes for color ASCII art in terminals that support them.
• Contrast adjustment: Boost image contrast before conversion for sharper ASCII output.
• Download as .txt: Save the ASCII art as a plain text file.

Frequently Asked Questions

What images work best for ASCII art?

High contrast images with clear subjects and simple backgrounds produce the best ASCII art. Portraits, logos, and bold graphic images work well. Busy, low-contrast, or small images produce muddy results.

Why does my ASCII art look stretched?

ASCII characters are taller than they are wide (roughly 1:2 aspect ratio). The converter compensates for this, but results may vary depending on your terminal or monospace font. If it looks stretched, adjust the width or aspect ratio setting.

Can I use ASCII art in a README file?

Yes. Wrap the ASCII art in a code block (triple backticks in Markdown) to ensure it renders in a monospace font, which is essential for ASCII art to display correctly on GitHub and documentation sites.

A 60-year history of text-based image art

Text-based image art predates ASCII itself. The earliest known computer portraits were produced by Kenneth Knowlton and Leon Harmon at Bell Labs in 1966 ; their famous «Studies in Perception I» (a reclining nude built from electronic symbols) hung in MoMA's «The Machine as Seen at the End of the Mechanical Age» exhibition in 1968. ASCII (American Standard Code for Information Interchange) was standardised in 1963 with 128 characters; teletype operators almost immediately started using it for printable «typewriter art», a tradition stretching back to RTTY art on radio teletype machines in the 1940s. The BBS era (1980s) and Usenet culture popularised ASCII signatures, banners, and the «emoticon», invented by Scott Fahlman at Carnegie Mellon in September 1982. Joan G. Stark, signing as «jgs», produced thousands of hand-crafted ASCII pieces during the 1990s that defined the aesthetic. FIGlet (1991, Frank, Ian and Glenn) automated big-letter banners. aalib (Jan Hubička, 1997) rendered moving images as ASCII; you can still pipe video through mpv --vo=aa. The 2010s brought Unicode-block art (using the half-block characters U+2580–U+259F for 2× vertical resolution) and braille art (U+2800–U+28FF packs 8 dots per cell, yielding 4× higher effective resolution than ASCII). Modern tools like chafa (Hans Petter Jansson, 2018) combine all three for the highest fidelity text-mode images.

Character ramps and brightness mapping

• The Paul Bourke ramp (10 levels). ` .:-=+*#%@ from light to dark, published by Paul Bourke at UWA in 1997. The de facto standard for terminal ASCII art. Reverse it for white-on-black terminals.
• The 70-character ramp. ` .'`^",:;Il!i><~+_-?][}{1)(|/tfjrxnuvczXYUJCLQ0OZmwqpdbkhao*#MW&8%B@$. Vastly more shading detail; ideal for portraits at width ≥ 100 columns. Originated on the «ASCII Art Generator» community circa 2010.
• Block characters (Unicode 2580-259F). ░▒▓█ for 4 brightness levels, plus half-block characters that let you encode two pixels per character cell. Doubles vertical resolution.
• Braille (U+2800-U+28FF). 256 distinct patterns of 8 dots per cell. Effectively gives you 2 horizontal × 4 vertical sub-pixels per character, quadruple the resolution of plain ASCII. Used by tools like drawille (asciimoo, 2014).
• The brightness formula. Each pixel is collapsed from RGB to a single brightness value before being mapped to a character. The classic formula is ITU-R BT.601 (1982): Y = 0.299R + 0.587G + 0.114B. The modern BT.709 (1990) variant for high-definition video uses 0.2126R + 0.7152G + 0.0722B. Both account for human eye sensitivity (greens dominate, blues contribute least).
• Character aspect ratio. A monospace character is roughly 2:1 tall:wide on most fonts (e.g. Consolas, Menlo, Cascadia Mono). If you sample the image at 1:1 pixel ratio, the resulting ASCII looks vertically stretched. Good converters sample every 2 rows but every 1 column to compensate.

Where ASCII art actually gets used

• GitHub READMEs. Logos and project banners as ASCII art in fenced code blocks render perfectly on GitHub, GitLab, Codeberg. Common in popular CLI tools (neofetch, htop, oh-my-zsh). Search «awesome ASCII art» on GitHub for collections.
• SSH Message of the Day (MOTD). Many servers display ASCII art when you SSH in. Ubuntu Server, Debian, OpenSUSE all support custom /etc/motd. Cloud providers (DigitalOcean, Linode) include them by default.
• System info utilities. neofetch (~2015), screenfetch, fastfetch, hyfetch (LGBTQ+ pride flag variant) display the distro logo as ASCII alongside system specs. Practically required in r/unixporn screenshots.
• Email and forum signatures. The original use case from the 1980s-1990s. Modern Hacker News, Reddit, IRC bots, and Discord (with monospace fenced code) still see plenty.
• Terminal video and games. mpv --vo=tct (true colour terminal) plays video in your terminal. NetHack, Dwarf Fortress, Cogmind, Caves of Qud are entire games built on ASCII/Unicode tiles. Browser ports: asciinema records terminal sessions.
• Generative and glitch art. ASCII conversion is destructive in a way that produces aesthetic artifacts. Used in zines, music videos, vaporwave / cyberpunk visuals, NFT collections like Loot derivatives.
• Teaching image processing. Brightness mapping, downsampling, gamma correction are easier to grasp when the output is human-readable characters. Common assignment in CS101 graphics courses.

Common mistakes that ruin the result

• Ignoring character aspect ratio. Sample every pixel and your output is twice as tall as the original. Skip every other row (or scale Y by 0.5) before sampling. Most ASCII art looks «squished» on inspection because converters forgot this step.
• Feeding in a low-contrast or busy photo. ASCII has only 10-70 brightness levels versus the source image's 256. Soft gradients become flat grey. High-contrast subjects on plain backgrounds (logos, portraits, silhouettes) work; sunsets and forests turn to mush.
• Setting width above 200 columns. Most terminals are 80-120 columns wide. Output that wraps mid-line is unreadable. For GitHub READMEs cap at 80 or use the «zoom in» browser feature.
• Inverted ramp on the wrong terminal. Light characters (., ,) need to map to dark image pixels if you'll view on a dark terminal (most modern ones). Inverted: dark characters (@, #) for dark pixels on a light terminal. Pick wrong and your image renders as a negative.
• Displaying outside a monospace font. Pasting ASCII art into Slack without a code block, into Notion as a paragraph, into a Word document with a proportional font: characters of different widths break the grid and you see noise. Always wrap in code blocks or use monospace explicitly.
• Converting JPEGs with heavy compression. JPEG's 8×8 block artifacts amplify into the ASCII output as visible grid noise. PNGs and high-quality JPEGs produce much cleaner ASCII; if you can re-export from the source, do.
• Pasting ANSI-coloured ASCII into a text file. ANSI escape sequences like \e[31m render in terminals but show as literal text in editors, GitHub, and chat apps. Save plain ASCII for documentation, ANSI for terminal output exclusively.

More frequently asked questions

How many characters wide should I make my ASCII art?

Match it to where you'll paste. For terminal output use 80 columns (still the default in most shells) or 120 for modern wide-screen terminals. For a GitHub README 80 is safe across desktop and mobile; 100 if you only care about desktop. For an email signature 60-70. For Discord/Slack 60 to keep within most users' message view. Above 200 is rarely useful, terminal wrapping kicks in.

Why does my output look better in some fonts than others?

Three reasons. First, the character aspect ratio varies: Consolas is roughly 2:1 tall:wide, Cascadia Mono is 2.1:1, Menlo is 1.95:1. Output tuned for one font looks slightly off in another. Second, line spacing: a font with a 1.2 line-height inserts vertical gaps that disrupt continuous shading. Set line-height: 1 when displaying ASCII art. Third, anti-aliasing: subpixel rendering blurs the boundaries between characters; turn it off in your terminal preferences for sharper ASCII.

Can ASCII art be converted back to an image?

In a sense, yes, but it's a lossy round-trip. Render the ASCII text in a monospace font at a small font size on a canvas, save as PNG; you get an image of the ASCII. Going the other way (ASCII → original photo) is not possible, too much information was discarded during downsampling and brightness flattening. Each character cell now represents perhaps 8×16 pixels of the original.

What's the difference between ASCII art, ANSI art, and Unicode art?

ASCII art uses only the 95 printable characters of the 7-bit ASCII set (1963), monochrome by definition. ANSI art adds escape sequences (the \e[31m style codes standardised in ANSI X3.64, 1979) for foreground/background colour and styling. Common on BBSes and modern lolcat. Unicode art uses the full Unicode range (16-bit and beyond) including block characters (U+2580-259F) and Braille (U+2800-28FF), giving 4-8× more resolution per character cell. True-colour Unicode art combines both: 16.7 million colours via ANSI true-colour codes plus Unicode block characters; this is what chafa and modern mpv produce.

Is my uploaded image sent to a server when I convert here?

No. Image decoding (via the browser's built-in image decoder), downsampling (via the HTML5 Canvas 2D API), brightness mapping, and character substitution all run locally in JavaScript. Open the Network tab in DevTools while converting; you'll see zero outbound requests for your image. Safe for confidential photos, NDA-bound work, family pictures, and unreleased product shots.