How I built an ASCII renderer over a weekend

I wanted the new app to have the look and feel of some of the dev tools I enjoy using, like Vercel, Cursor and Linear.

It had to be simple enough that anyone could drop a file in and get the output they wanted, and deep enough for someone who wanted to play around and tweak every setting.

I went for a clean, technical look without any gradients, glows or glass effects. A dark graphite theme with thin lines and a bright orange accent. Keyboard shortcuts cover the whole app, and a status bar shows stats for nerds.

Upon investigation, I found that the initial build sized each character by how big the letter M looked, instead of the font's real character width and line height. That made every exported image noticeably wider than the original. I fixed this by measuring the font once and building every export from one shared grid, so the aspect ratio is preserved in exports.

Initial build · Python + Flask

New app · WebGL2 in the browser

Other than this, the initial build couldn't render GIFs or video, and the renders were painfully slow, since everything ran in Python on the CPU. I moved the whole pipeline to the GPU. Now the preview updates in real time as you modify the parameters, and GIFs and videos play and export at their original speed.

The characters also didn't quite match the image. The initial build drew each character centred in its cell instead of on the font's baseline, so ., - and _ lost the position that tells them apart. It also measured characters and images in slightly different ways. Now every character sits on its real baseline and is measured exactly like the image.

The new app opens with a redesigned homepage. You can now render ASCII art from an image, GIF or video file on your device, in the clipboard or at a link, and even use your device's live camera feed. You can also simply drag the file you want to convert and drop it in the drop zone.

If you want to get started quickly, there are a few samples to select from just below the drop zone. Click on one and that's it. The sample opens in the editor with its settings already applied.

The footer notes that everything is processed in the browser, and the files you open stay on your device.

The editor keeps the focus on the live preview. The controls sit in a panel on the right, grouped into sections for the mode, grid, tone, colour and more. To keep the panel easy to scan, each control shows only its label and value, and hovering over a label shows a tooltip explaining what it does. Every change can be undone and redone. On a phone, the modes sit along the top and the controls move into a sheet under the preview.

Rulers along the top and left of the preview count columns and rows. Hovering over a cell shows its column and row, the character in it and its brightness. The status bar at the bottom shows the grid size, how long each frame takes to render and the frame rate.

The Split view compares the render with the source image, or with a plain brightness-only render of the same image.

GIFs and videos also get a timeline for scrubbing through the clip, stepping through it frame by frame, trimming it with In and Out points, looping it and changing its speed.

The app has five modes to switch between.

ShapePicks each character by both brightness and shape, so characters follow the edges.

RampPicks characters by brightness alone, from the classic ramp of characters sorted from sparse to dense.

BrailleSplits each cell into a 2 × 4 grid of braille dots, and every character carries eight dots of detail.

HalftoneDraws a grid of dots, rotated 45° the way print halftones are, with each dot sized by the brightness under it. The dots can also be squares, diamonds or lines.

BlocksSplits each cell into 2 × 2 quarter blocks.

The app comes with built-in presets for Line art, Soft photo, Braille dots, Halftone print and Teletext. You can also save your own.

Every mode also works in three colour themes.

MonoUses one ink for the whole render.

SourceTakes each cell's colour from the image.

DuotoneBlends two inks based on brightness.

You can export your ASCII render as PNG, SVG, TXT, HTML, GIF, MP4 or WebM. GIF and video exports keep the clip's frame timing, MP4 and WebM formats keep its audio too, and the webcam can be recorded straight to video.

The PNG, the SVG and the text can also be copied straight to the clipboard, ready to paste wherever you need them.

Keyboard shortcuts cover the whole app, and pressing the "?" key shows all of them in one modal. When you move through the app with the keyboard, the focused control has an orange outline.

All text meets the WCAG contrast minimum of 4.5:1 against the dark theme, including the dimmest labels, and every button and slider has a hit area of at least 32 pixels. All buttons have tooltips that show their shortcut. States are not shown by colour alone. Selected items also have a bar and a border, and disabled options include clear reasoning.

For screen readers, all buttons are labelled, the preview has a text label with the file name and grid size, for example "ASCII render of torus.png, 160 by 45 cells", and actions like switching modes or Undo are announced. For the systems set to reduce motion, the app removes its sliding animations and the looping loading indicator.

The app runs entirely in the browser. There's no server.

It has four main parts.

1. 01The media layer reads files and the webcam, including every frame of a GIF or video.
2. 02The renderer turns each frame into characters on the GPU, using WebGL2.
3. 03The exporters turn the result into files.
4. 04The interface sits on top.

The preview and every export come from the same grid. This is what fixed the aspect ratio bug from the initial build. The preview is drawn by the same code that draws the exports, so what you see is what you download. And since every change redraws the preview on the next frame, there's no need for a Render button.

Long exports like GIF and video are encoded in the background, so the app stays responsive and you can cancel them at any point. For browsers without WebGL2, a slower copy of the renderer runs on the CPU.

The app cuts the image into a grid of cells. Instead of measuring each cell's overall brightness, it reads six small circles inside the cell. Together, the six readings capture the cell's brightness and shape, which the app uses to pick the right ASCII character.

Cut into cells

Six readings per cell

Closest character by brightness only

Closest character by brightness and shape

This works a lot like word embeddings, the vectors language models use to place words with similar meanings close together. The six readings form a six-dimensional vector for each cell, and every character in the font gets one too. Picking a character is then a nearest-neighbour search using a weighted Euclidean distance, the same kind of vector search that retrieval in RAG systems is built on.

Read more about the architecture and the algorithm in the project's notes on GitHub.

In the initial build, I followed Harri's approach almost line for line. The new app keeps the idea but changes three things around it.

1. 01Comparing every cell with every character was too slow on a CPU, so Harri sped it up with a faster search and a cache that rounds each reading. That cache caused bugs in the initial build, where it picked the wrong character for 5 to 32% of cells. The new app compares every cell with every character on the GPU, where it's fast enough, so it always picks the closest character.
2. 02A flat grey cell has no shape, so only characters with evenly spread ink could match it, and smooth areas filled up with | and !. The new app gives shape less weight when a cell has little shape of its own, so edges are matched as before and smooth areas keep their tone.
3. 03Harri's article moves past the classic brightness ramp, .:-=+*#%@. I kept it as Ramp mode, because it suits some soft photos, and next to Shape in the Split view, it shows the difference shape matching makes.