ascii-draw is a GTK4 drawing app where the canvas is made of characters

What the application is for

ASCII Draw is an application for creating diagrams and artwork using only ASCII characters, and the README's own framing is sketch anything using characters. The description calls it a powerful and intuitive application that lets you draw diagrams, tables, tree views and art using only characters.

The stated contexts are documenting code, creating technical diagrams, and expressing creativity, and the feature list says it provides all the professional tools you need for those.

The what you can create list is more specific and is the better guide to what the tool is actually used for. Technical diagrams covering flowcharts, network diagrams and system architectures. Code documentation, described as visual representations for README files and documentation. Data visualization, tables, charts and structured data displays. Creative art, ASCII art and decorative elements. Educational content, visual aids for presentations and tutorials. And organizational charts, tree structures and hierarchical displays.

Two of those categories matter more than the others for an engineering audience. README documentation is the case where an ASCII diagram beats a screenshot, because a character diagram is diffable in a pull request, searchable with grep, and readable in a terminal or a plain text viewer. And tree views and organizational charts are the case where a grid of characters is the natural representation anyway, because the structure is a hierarchy and the layout is a grid.

The application is Python, licensed GPL-3.0, with the default branch master. The topics name ascii, ascii-art, ascii-table, gnome, gtk4 and libadwaita, so it is a GNOME technology stack application rather than a web or terminal tool. The homepage given in the repository metadata is the Flathub listing, and the app id is io.github.nokse22.asciidraw, which follows the reverse domain name convention for a GNOME application. The last push was on 2026-07-16, and the recent releases are v1.3.0 from 2025-11-28, v1.2.0 from 2025-11-26 and v1.1.0 from 2025-05-04.

The tool set, and which of the tools matter

The tool set is a list of eleven capabilities, and reading them shows what the editor is really doing.

The rectangle tools come first, with multiple line styles for borders and frames, followed by filled rectangles with customizable border and fill characters. Those two are the backbone of any character-based diagram, because a box drawn with a single line character looks different from one drawn with double lines, and a filled box is how you shade a region in a diagram without colour.

Line drawing follows, with Cartesian, Freehand and Stepped lines with optional arrows. Three line types is a considered choice: Cartesian lines snap to the grid and go horizontal, vertical and diagonal, which is what you want for a flowchart; freehand lines are for the artistic case; stepped lines are the orthogonal style used in network and system diagrams where connections route around boxes.

Then the freehand brush for natural drawing, and text with FIGlet fonts, which is a stylised text using beautiful ASCII font styles. FIGlet is the standard library of large decorative text banners, and using it means a diagram can have a proper heading rendered in a banner font rather than in the same characters as the rest of the drawing. The dependency list includes pyfiglet, which is the Python binding.

The remaining tools are the ones a drawing application needs to be usable. The table creator for professional table formatting and alignment, which is the answer to the ascii-table topic tag and to anyone who has hand-aligned a table in a code block. The tree view for hierarchical structures and organizational charts. The eraser for precise deletion and editing. A character picker with an extensive library of ASCII characters and symbols. Selection tools to move and rotate selections. And flood fill to quickly fill areas with chosen characters.

Flood fill is worth flagging as the one tool that is hard to do well in a character grid. Because the canvas is characters and not pixels, a fill has to decide what counts as a region, and in a text canvas with spaces, lines and box characters, the adjacency rules are not obvious. That it is listed as a feature suggests the author worked out a usable answer.

The two dependencies that go with these are the emoji package, for the character picker's non-ASCII entries, and libadwaita, the GNOME widget library that gives the application its visual style.

Installing it: Flatpak or a source build with Meson

There are two routes, and the README presents them in that order.

The first is a Flatpak from Flathub, with the download badge linking to the Flathub listing. The application id is io.github.nokse22.asciidraw, and the README's Flathub badge is a dynamic one that reads the install count from the Flathub API, so the number on the badge is current rather than a static image.

The second is from source, for developers and contributors who want to build from source:

# Clone the repository
git clone https://github.com/Nokse22/ascii-draw.git

cd ascii-draw

# Open in GNOME Builder and click "Run Project"

Three commands and then an IDE, which tells you the intended development path. GNOME Builder is the GNOME IDE, and the repository layout supports it: there is a meson.build at the top level, a build-aux/ directory, a po/ directory for translations, data/ for the application data and resources, src/ for the source, and io.github.nokse22.asciidraw.json as the Flatpak manifest.

The meson.build at the root is the giveaway about the build system. Meson is what GNOME applications use, and it is what GNOME Builder drives, so the two are the same workflow. The presence of po/ means the application has translations, and a po/ directory in a Meson project is paired with gettext and a translation template, so the application is set up to be localised.

The Flatpak manifest at the top level is what makes the Flathub build reproducible. A Flatpak pins the runtime and every dependency, which is why the Flatpak route and the source route can behave differently: the Flatpak carries its own copy of GTK4 and Python, while a source build uses whatever your system has.

The system requirements are listed separately for the source route: Linux with the GNOME desktop environment recommended, Python 3.8 or higher, and the dependencies GTK4, libadwaita, pyfiglet and emoji.

Saving, and why the output format is the constraint

The screenshots section describes the save options in one line: save as text file or copy to clipboard. That single phrase tells you what the application produces and, by implication, what it cannot do.

Every piece of work in this editor is a grid of characters, and the two output paths are both plain text. A saved file is a text file containing the characters, and the clipboard carries the same content. That is the right output for the stated use cases, because a README, a code comment or a chat message needs exactly that, and a text file is diffable, grepable and renders identically everywhere.

The consequence is that there is no vector or raster export. There is no PNG of your diagram, no SVG, no PDF. If you need a diagram as an image for a slide deck or a print document, this is not the tool, and you would end up taking the text and rendering it somewhere else, at which point you have lost the alignment work the table creator did for you unless the renderer is monospaced.

That monospace requirement is worth stating plainly too, because it constrains where the output can be used. A character diagram only lines up in a monospaced font. Paste it into a proportional font and the boxes shear. The application itself obviously assumes monospace, and the README does not say so, but any document you put the output into has to keep the font fixed for the drawing to survive.

The screenshot set also shows the other parts of the interface. There is a drawing interface with the various tools, a text features screen showing advanced text manipulation and formatting options, a character selection screen, the drawing tools themselves, and the save options. The character selection screen with a wide selection of ASCII characters and symbols is the one that indicates how the application handles the character picker in practice, since a grid editor that is mostly a large palette plus a few geometric tools is a different thing from a conventional raster editor.

For chat, the README points at a Matrix room, #ascii-draw:matrix.org, for sharing what you made or asking for help when contributing.

Where ascii-draw is the wrong tool

Three limits, and the first is about the output format.

The first is that the output is characters, which is the feature and also the ceiling. A diagram made of characters cannot convey gradients, colour, or a shape that does not have a character representation, and the whole craft of making one readable is working within that constraint rather than against it. If the deliverable is something a reader will look at once, in a browser, an SVG or PNG diagram communicates more per unit of effort. If the deliverable lives in a repository, in a terminal or in a code comment, ASCII is better because it diffs, it greps and it survives a paste into a terminal.

The second is the platform. The system requirements ask for Linux with the GNOME desktop environment recommended, the dependencies are GTK4 and libadwaita, and the build is Meson and GNOME Builder. There is no Windows or macOS story in the README, and the Flathub distribution covers Linux only. That is a narrower audience than the tool's utility deserves, since character diagrams are a universal need, and a browser-based editor would serve anyone. As it stands, you need a Linux desktop with GNOME.

The third is that the feature list is a list of drawing tools, not of a document format. There is no mention of layers, undo history, export to a diagram language like PlantUML or Mermaid, or version control of the drawing itself. The tree view and table creator are conveniences for producing a specific kind of output quickly, not a document model. So if your workflow involves editing a diagram repeatedly, or converting a diagram into code, this tool is at the end of that pipeline rather than in the middle of it.

The alternative approach is to write the characters directly, in a text file, with a monospaced editor, which sounds primitive but is what a lot of people do for a small ASCII diagram in a README. The difference in approach is that ascii-draw gives you alignment, line styles, flood fill and a table creator, so a fifty-row diagram costs minutes instead of an afternoon, and the character picker means you are not hunting through Unicode tables for a box-drawing glyph. For a one-off five-line diagram, a text editor is faster. For anything you will look at more than once, the editor is worth the installation.

Editorial conclusion

Adopt ascii-draw if you need to produce ASCII art or character-based diagrams for a README, a terminal-friendly doc or a chat message, and you want a real editor with line styles, alignment and flood fill rather than a text file you hand-align. Do not adopt it if you need the output to be vector or a bitmap, because the whole canvas is characters and the export paths are text file and clipboard. Verify first that you have a GNOME desktop, since the system requirements ask for Linux with the GNOME desktop environment recommended, that your Python is 3.8 or higher and that GTK4, libadwaita, pyfiglet and the emoji package are installed, that you can build from source with Meson and GNOME Builder if you want the newest changes, and that the Flatpak build on Flathub matches the version you need.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Nokse22/ascii-draw on GitHub
3. Project website
4. README
5. Releases