ASCII Art Generator
Rebuild an image out of characters. Pick a glyph set and how many characters wide the result should be — every ramp is ordered by the ink each glyph actually covers in your browser's own font, measured when the page runs.
Drag & drop a file here, Ctrl+V to paste, oror
The ramp is measured, not assumed
A glyph set is only a ramp if its characters really run light to dark, and that depends on the font your browser resolved. Each glyph is drawn once and its inked area counted, then the set is sorted by that number — so no order is claimed that this font does not have.
Character cells are not square
A monospace cell is roughly twice as tall as it is wide, so sampling square blocks and printing them as text stretches the picture. The ratio is read from the font's own advance width and line height, and the sampled block is shaped to match it. The figure is printed under the output.
100% private
Your image never leaves your device. The pixels are read on the Canvas API in your browser, the text is built locally, and the .txt and PNG downloads are generated on your machine. No upload, no storage, no account.
How it works
What the converter actually does
The image is divided into a grid as many columns wide as you ask for, the average brightness of each cell is measured, and one character is printed in that cell. That is the whole method: nothing is estimated and nothing is judged. The line under the output prints the parameters that produced it, including the two numbers this tool measures rather than assumes — the shape of a character cell in your font and the range of ink the chosen glyph set covers.
Why the ramp is measured in your browser
Almost every ASCII converter ships a ramp written as a fixed string, light to dark. That order belongs to whatever font its author was looking at, and it is not portable: a browser that resolves the monospace stack to a different face changes which glyph is darker than which, and the output still looks like ASCII art while the tones inside it are wrong. So the ramps here are declared as sets, not as orders. Each glyph is drawn once into its own cell, the alpha it puts down is summed, and the set is sorted by that measurement. Picking a glyph for a cell is then nearest-coverage, not position: real font glyphs are not evenly spaced in density, and indexing by position would claim they are.
Cell aspect, width and detail
A monospace character cell is about half as wide as it is tall, so a converter that samples square blocks produces a result stretched to roughly twice its proper height. The ratio is taken from the resolved font's own advance width and line height and the sampled block is shaped from it, which is why the figure under the output is a decimal rather than a round number. Output width is given in characters because that is the unit text is quoted in: forty characters reads as a coarse icon, a hundred is a good default, and two hundred and forty holds real detail but needs a wide screen or a small type size to be read as a picture. Nothing smaller than one cell can appear at all.
Where it runs, and what it is not
Everything happens in your browser through the Canvas API. The image is never uploaded, nothing is stored, and no account is needed. Two limits worth stating plainly. The coverage figures are not portable: they describe the font your browser resolved right now, so the same picture pasted into an editor with a different monospace face will not carry exactly the tones you saw here. And the darkest a cell can go is however much ink the densest glyph in the ramp covers — a ten-glyph ramp cannot reach solid black, which is why the block-element set exists. For the pixel-level version of the same reduction see Dithering, and for the printed-dot version see Halftone.