A local ASCII art generator can convert a JPG, PNG, or WebP file up to 15 MB into a grid of monospace text characters without ever leaving your browser tab. The conversion follows a fixed pipeline: the source picture is decoded and shrunk to one pixel per output cell, each sampled pixel is mapped to a relative luminance value defined by WCAG 2.2, and that luminance picks a character from the chosen density sequence. The end product is plain text — no image, no embedded base64 — that you can paste into a code block, a chat reply, or a long comment without dragging a picture along with it, though the final appearance still depends on the destination's font, line height, and available width. This local pipeline also means there is no queue to wait in if a remote server is busy. ASCII text survives in places that reject image attachments, including plain README files, terminal screenshots, source-code comments, IRC-style logs, and forum posts that strip binary uploads. The trade-off is that ASCII is an interpretation rather than a lossless image format — fine texture, true color, and small readable type in the picture will not survive the conversion. Treat the output as a stylized, recognizable sketch of the original rather than a copy.
What this tool actually does to your image
The Text to ASCII Art Generator converts a picture into text by sampling it down to a tiny grid and replacing each sampled pixel with a single character. The sampled image is first drawn onto a small canvas that preserves the source aspect ratio, so a wide photo becomes a wide text block and a tall portrait becomes a tall text block. Because monospace characters are taller than they are wide, the tool applies a height correction before counting rows; without that step a square picture would look vertically stretched after the conversion. Each output cell corresponds to exactly one composited sRGB pixel, which is why the result is shaped like the original even though it contains no actual picture data; the browser reads those pixels through the standard canvas getImageData interface.
After sampling, every pixel is converted from its sRGB channel values to a linear value and run through the relative luminance formula documented in WCAG 2.2. That luminance — a single number between zero and one — selects a character from the density sequence you picked. Visually heavy glyphs such as @, #, and M represent darker areas, while spaces and small punctuation marks represent lighter ones. This is why a portrait becomes a recognisable cluster of dense characters around the face and sparser rows around the background. The whole pipeline runs in the current tab, so the intermediate preview is available as soon as the conversion finishes.
Inputs the tool accepts and the limits that gate them
Only three image formats are accepted: JPEG, PNG, and WebP. The browser rejects anything else before the file is decoded, which keeps an unsupported extension from triggering a wasted load. The first hard limit is file size: any image larger than 15 MB is blocked up front, before the dimensions are even read. This rule exists because decoding very large files in a single browser tab can fail on memory-constrained devices, especially phones with several tabs open in the background.
After the file passes that gate, the browser reads the decoded dimensions and checks a second ceiling around 40 megapixels. That ceiling cannot be enforced before decoding because the file size of a compressed image does not predict its decoded dimensions reliably — a small but very high-resolution PNG can be tiny in bytes and huge in pixels. The 40-megapixel ceiling limits subsequent canvas processing. If the output would produce more than 800 rows or 100,000 characters at the chosen width, the tool refuses to render and suggests a smaller width or a cropped source. Those guardrails exist because a result past those thresholds becomes hard to inspect, copy, or paste into any real layout.
| Limit | Value | Where it is checked |
|---|---|---|
| Accepted file types | JPEG, PNG, WebP | Before decoding |
| Maximum file size | 15 MB | Before decoding |
| Maximum decoded pixels | up to ~40 megapixels | After the browser reads dimensions |
| Maximum output rows | 800 | After the sample grid is calculated |
| Maximum output characters | 100,000 | After the sample grid is calculated |
Width, density, and Reverse: the three controls that change the look
Three controls decide how the conversion looks before you click Generate. Output width is the number of character columns in the result. A larger value preserves more small features from the source — facial details, lettering on a logo, thin lines — but it also produces longer lines and a larger total text block. A smaller value shortens every line and gives a more compact sketch that pastes neatly into narrow layouts such as sidebars, profile bios, or terminal windows capped at 80 columns. There is no single best width; the right number depends on the destination and on how much detail the source picture actually carries.
Density set controls how many tonal steps the converter has to choose from. Standard is the balanced default and works for most subjects. Detailed gives the converter more symbols per luminance step, which is useful when a subject is monotone and would look like a wall of identical characters at Standard. Simple uses fewer symbols and tends to look bolder, which can rescue a busy, high-contrast source that turns into visual noise at higher densities. The Reverse toggle flips the luminance direction so that bright areas of the source become the heaviest characters and dark areas become spaces. Enable it when the destination renders light text on a dark background, such as a dark code block, a dark-theme chat window, or a terminal using the standard white-on-black palette.
| Density set | Behaviour | Best for |
|---|---|---|
| Standard | Balanced default sequence | General subjects, photos, mixed contrast |
| Simple | Fewer symbols, bolder result | Noisy or high-contrast sources that need cleanup |
| Detailed | More symbols per luminance step | Monotone subjects that need extra shading |
How to create ASCII art from a local image
Use this short workflow to produce a pasteable ASCII block from any supported picture.
- Choose a JPG, PNG, or WebP file from your device and wait for the converter to display its pixel dimensions.
- Set the output width in columns, choose a density set, and toggle Reverse if your destination uses light text on a dark background.
- Click Generate and inspect the monospace preview; every character should occupy a predictable visual cell.
- Copy the text to your clipboard, or download it as a UTF-8 plain TXT file named after the source image.
The first step is file selection — the file picker accepts only the three formats above and rejects anything else. Once a valid file is loaded, the dimensions appear because the browser has already decoded the image locally. The second step is where you choose the trade-off between detail and length: a wider output keeps more small features, while a narrower output keeps the result compact enough to paste into a narrow code block. The third step is the actual conversion, and it is where you discover whether your settings worked — the preview is rendered in a monospace font so each character occupies a predictable cell. The fourth step is output: Copy places the exact text on the system clipboard, while Download TXT creates a plain UTF-8 file that you can open in any text editor or pipe into another local script.
Choosing between Copy and Download TXT
Copy and Download TXT produce the same character rows, but they fit different workflows. Copy puts the exact text on the system clipboard, ready to paste into a chat reply, a code block, or any text field that accepts paste. Download TXT writes a UTF-8 plain-text file named after the source image; the file contains only the generated rows, with no header or metadata, so it can be opened in any text editor, diffed against a previous version, or piped into another local script. If you intend to paste the result into several places, Copy is faster. If you intend to keep the result alongside the original picture or share it as a file, Download TXT is the cleaner choice. Either path runs locally, so the text never traverses a server in between.
Reading the monospace preview before you copy or download
Always read the preview before treating the result as final. ASCII is a lossy interpretation of the source, not a pixel-faithful copy, so the same width and density can produce very different results on different pictures. A good starting point is around 80 columns with the Standard density set. Generate once, then look for two things: recognisable edges of the main subject, and overall tonal balance. If important edges blur into the background, increase the width or switch to Detailed. If the preview feels noisy with too many small symbols fighting for space, switch to Simple or drop the width by 10 to 20 columns.
Keep the original picture available while you iterate — you may need to revisit it to confirm a feature the converter flattened. The tool also rejects outputs that exceed the 800-row or 100,000-character guardrails, so if the converter asks for a smaller width or a cropped source, that is the correct response rather than a workaround to bypass. Once the preview looks right at the chosen width, copy or download it; the output is fixed at that point and there is no need to regenerate unless you change a setting.
Where ASCII text pastes cleanly — and where it breaks
Where you paste the result matters as much as the settings you used to create it. A monospace destination preserves alignment, while a proportional font will silently stretch the columns and ruin the shape. Some platforms collapse repeated spaces unless the text is wrapped in a preformatted block, so a background that looks solid in the preview can develop holes when pasted into a chat window that strips whitespace. Code blocks, Markdown fences, README files, terminal paste buffers, and any container explicitly set to a monospace font are reliable targets. Plain chat messages, rich-text editors with autoformat, and word processors with smart-quote or autocorrect features are common failure cases — paste into those only after previewing.
To check whether a destination will preserve your result, paste the same block into both a code block and a plain message in your usual chat tool; if the two look different, the destination is changing the rendering rather than the converter producing a flawed output. To learn more about the pixel-to-character mechanics behind the preview, the Image to ASCII Explained: How Pixels Become Text guide walks through the same sampling and luminance stages this tool uses.
For a deeper look, see How to Use Canva to Combine Images: A Local Shortcut.