Retype a photograph as ASCII characters

Everything this page does is built on one object: a grid of characters, with an optional colour per cell. The lab divides your photograph into cells, averages each one, and chooses the character whose ink coverage on the page matches that average — a heavy glyph for a dark patch, a light one for a pale patch, a space for white.

The picture and the text file are two renderings of that single grid rather than two separate conversions of the photograph. That is a deliberate structural choice and it has a visible payoff: the file you paste into a terminal and the image you post are guaranteed to contain exactly the same characters in exactly the same places. Tools that build the two independently drift, usually in the row count.

Characters

Ten steps is blunt, legible and the right default. Seventy steps resolves much more tone but needs a large grid to show it. Blocks are the four shaded box-drawing characters and a space, which give flat coverage and look least like typing. Your own takes any string of two characters or more, darkest first.

Columns, 40 to 400

How many cells across the picture is divided into. The row count follows from your photograph's proportions with the monospace correction applied, and the readout shows the grid you will actually get.

Colour the characters

On, each character takes the mean colour of the patch it stands for, which keeps a surprising amount of the original photograph. Off, a single ink is chosen to stand clear of the ground below, so a dark ground gives a terminal and a pale one gives a typewriter.

Ground colour

What sits behind the characters, and what anything transparent is composited onto before a cell is measured — otherwise an empty pixel reads as black and puts a wall of heavy glyphs around a cut-out.

Ten or seventy steps of tone is not many, and the pictures that survive the reduction are the ones that were already legible as shapes. A silhouette against a bright sky comes through perfectly. A portrait lit from one side comes through. A busy street scene with everything at a similar brightness becomes texture, because every cell is asking for the same character.

Column count is the other half of it. More columns is not more detail past a certain point — it is more cells, each measuring a smaller and therefore noisier patch, and a noisy patch produces a character that jumps around between neighbours. If the result looks like static, go coarser rather than finer.

Choose Plain text in the export step and you get a .txt with one line per row and nothing else — no wrapper, no metadata, no trailing spaces beyond what the ramp put there. It pastes into a terminal, a code block, a message or a monospaced document and lands exactly as it looks here, provided whatever receives it is using a monospaced face. In a proportional face it collapses immediately, because every assumption behind the grid is that all the characters are the same width.

Colour is not carried into the text file, since a .txt has nowhere to put it. If you want the coloured version, export it as a picture; PNG holds the flat colours of a character grid well.

Why are there fewer rows than the proportions suggest?

Because a monospace character cell is about twice as tall as it is wide, and a grid with as many rows as columns would render your photograph stretched to twice its height. The lab halves the row count to compensate, which is why 120 columns on a 3:2 photograph gives roughly 41 rows rather than 80. Every ASCII renderer has to make this correction; the ones that look wrong are the ones that skipped it.

What does the 400-column limit actually protect me from?

A document. Four hundred columns on a tall photograph is around nine hundred rows, which is three hundred and sixty thousand positioned characters, and no browser lays that out happily — the tab goes unresponsive and the export takes far longer than anyone expects. The lab holds the grid to 140,000 cells and says so under the slider, rather than accepting a number it cannot honour.

Is the text file the same as the picture?

It is the same document with the drawing step skipped. The grid is built first — rows of characters, plus an average colour per cell when colour is on — and the picture is that grid drawn at whatever size the export is running at. So the .txt and the PNG cannot disagree about which character sits where, which is not true of tools that convert to text and to an image by two separate routes.

How do I pick a character ramp?

By how much detail you have to spend. The ten-step ramp is blunt and reads clearly at small sizes. The seventy-step ramp resolves far more tone but needs a large grid before the difference is visible, and it mixes wide and narrow glyphs, which adds its own texture. Blocks give clean flat coverage and look least like typing. If none of them suits, type your own — darkest character first, lightest last, two or more of them.

• PixelateSquare or hexagonal blocks, each one flat, with optional palette quantisation.
• HalftoneDots on a rotated screen, one plate or four, with the angles a press would use.
• The effects labAll six effects, chosen from your own photograph rather than from a list of names.
• Effects, and why they are not filtersThe one test that sorts a colour grade from a rebuild, applied to fifteen awkward cases.

Rendered on your computer, not on a server.