# Svgbob: turning ASCII diagram scribbles into SVG

> Svgbob is a Rust tool that reads text diagrams and writes SVG. It is aimed at people who keep architecture sketches in plain text files and want them rendered without leaving the terminal.

**ivanceras/svgbob** — Convert your ascii diagram scribbles into happy little SVG

- Repository: https://github.com/ivanceras/svgbob
- Website: http://ivanceras.github.io/svgbob-editor/
- Stars: 4,232 · Forks: 127
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/ivanceras-svgbob

## What Svgbob solves, and who it is for

The project describes itself plainly: "Svgbob can create a nice graphical representation of your text diagrams." The input is ASCII art of the kind engineers have drawn in comments and READMEs for decades. The output is an SVG image. That is the whole contract.

The people who benefit are the ones who already write diagrams as text. A box drawn with plus signs and dashes, an arrow made of hyphens and a greater-than sign, a labelled cylinder: these survive in a Git diff, they can be edited in any editor, and they do not require a binary file format. What they lack is a presentable rendering. Svgbob supplies that rendering without asking the author to redraw anything.

The README lists where this has mattered in practice. Google's comprehensive-rust uses it through mdbook-svgbob. Asciidoctor supports it as a diagram type. There are integrations for Discourse, Typst (bob-draw), Zola and Kroki. That list is the clearest signal of the intended audience: documentation pipelines, not desktop drawing.

## How the ASCII-to-SVG conversion works

The repository is a Cargo workspace with three members: crates/svgbob, crates/svgbob_cli and crates/svgbob_server. That split is the architecture in miniature. The library crate holds the conversion logic, the CLI crate wraps it for terminal use, and the server crate exposes it over HTTP for the editor demo hosted at ivanceras.github.io/svgbob-editor.

The README states that the CLI "takes text as an input and creates an svg image as an output". The transformation is therefore a pure text-to-text operation at the boundary: characters in, SVG markup out. There is no intermediate binary format to manage and no state to persist between runs, which is why the integrations listed above can call it as a one-shot step inside a larger build.

How the parser decides which characters form a line is not described in the README. The README points to a separate Specification page for that, and the repository carries an Architecture.md and a TODO.md alongside the crates. Anyone who needs to know the exact rules, for instance whether a particular junction character closes a box or is ignored, has to read the specification rather than the README.

## Installing Svgbob and rendering a first diagram

The README carries a crates.io badge, so the published package is the normal entry point. The workspace layout means the CLI crate is what you want on your PATH. The README itself gives no install command, so the crate name comes from the workspace member list rather than from a documented step.

With a binary built from the CLI crate on your PATH, the workflow is a file in, a file out. Write a diagram to a text file first, then point the tool at it. The README gives no flag names, so check the tool's own help output for the exact input and output arguments your build provides.

According to the README, the CLI takes text as input and creates an SVG image as output, so a shell redirect is the simplest shape of a run. Open the resulting file in a browser or embed it in a page.

If you would rather not build a binary, the README links a browser editor at ivanceras.github.io/svgbob-editor, which runs the same conversion through the server crate. That is the fastest way to check whether your particular ASCII shapes render the way you expect before wiring anything into a build.

## Where Svgbob stops being the right tool

The input format is the limitation. A diagram that needs diagonal lines, curves, or text rotated to an angle cannot be expressed in the character grid Svgbob reads. The specification defines which arrangements of characters are recognised; anything outside that set is either ignored or drawn literally, and the README does not say which. If your diagram depends on a shape the specification does not cover, you find out by rendering it.

There is also a maintenance question worth stating plainly. The most recent release listed for the project is 0.5.5, published on 2021-08-16. The last push to the repository was on 2026-04-22. Work has continued on the branch, but the crates.io version is from 2021, so a published package and the master branch are not the same code. If you need a fix that landed after that release, the crates.io route will not carry it and you are building from source.

Finally, the tool renders; it does not edit. There is no round trip. Once the SVG exists, changing the picture means changing the ASCII and regenerating. For diagrams that are stable, that is fine. For diagrams that are redrawn weekly, it is friction.

## Svgbob compared with Ditaa and Asciitosvg

The related searches around this project keep returning to Ditaa and Asciitosvg, and the comparison is fair because all three read the same family of input. The difference is in the implementation and the delivery.

Ditaa is the older Java tool in this space. Its approach is to interpret ASCII shapes and paint them into an image, and it has historically been used from build scripts and editor plugins. Svgbob is written in Rust and its output format is SVG specifically. That choice matters for documentation: SVG scales without pixelation and its text remains selectable and searchable in the rendered page, which a raster output cannot offer.

Asciitosvg takes a different route again, treating the ASCII as a source for a diagram description that is then laid out. The practical consequence for a reader choosing between them is what happens when the ASCII is ambiguous. Svgbob's answer is a published specification page that defines the recognised constructs. A tool without that document leaves you guessing from examples.

None of these differences make one tool correct in the abstract. If your pipeline is already JVM-based, Ditaa fits without adding a Rust toolchain. If you want the SVG to be the artefact that ships with your docs, Svgbob's output format is the reason to pick it.

## Maintenance cost, licence and what a build actually pulls in

Svgbob is licensed under Apache-2.0, and the repository carries a LICENSE file at the top level. That is a permissive licence, but the usual caveat applies: if you redistribute the binary or embed the library in a product, read the licence text yourself rather than relying on a summary. Nothing here is legal advice.

On upgrade cost, the workspace pins dependencies through Cargo.lock, and the root Cargo.toml sets a release profile with opt-level 3, link time optimisation and codegen-units 1. Those settings trade build time for a smaller, faster binary. If you build from source in CI, expect the release profile to be the slow part of the job.

The repository also carries deny.toml, which is the cargo-deny configuration used to check licences and dependency sources, and a snapcraft directory for Snap packaging. Both are signals that the project has thought about distribution beyond crates.io. The README does not document a rollback path or a version compatibility policy, so if you need to pin a specific behaviour, pin the crate version explicitly in your own manifest.

## Conclusion

Adopt Svgbob if your diagrams already live in plain text inside a README, a Markdown book or an Asciidoctor page, and you want an SVG rendering without a drawing application. Do not adopt it if you need interactive editing, precise layout control, or diagrams that change shape often; keeping the ASCII and the rendering in sync is manual work. Before committing to it, verify two things: that the current master branch builds from source in your toolchain, and that the shapes you draw are covered by the specification, because the README itself does not document what happens to characters Svgbob does not recognise.

## FAQ

### How do I install Svgbob?

The README carries a crates.io badge and the workspace contains a crates/svgbob_cli member, so the CLI crate is the component to build or install. The README does not print an install command or list flags, so check the tool's help output after installation.

### Does Svgbob output PNG or only SVG?

The README says the CLI takes text as input and creates an SVG image as output, and SVG is the only output format it names. There is no mention of a raster export in the README.

### Can I use Svgbob inside Markdown or Asciidoctor documents?

Yes. The README lists integrations for Google's comprehensive-rust via mdbook-svgbob, Asciidoctor as a diagram type, Discourse, Typst through bob-draw, Zola and Kroki. Each of those wraps the same conversion.

### Which ASCII shapes does Svgbob recognise?

The README links a separate Specification page for the recognised constructs and does not reproduce the rules itself. The repository also carries an Architecture.md and a TODO.md, so the specification page is the place to check before relying on an unusual shape.

## Sources

- [ivanceras/svgbob on GitHub](https://github.com/ivanceras/svgbob)
- [License: Apache-2.0](https://github.com/ivanceras/svgbob/blob/master/LICENSE)
- [Project website](http://ivanceras.github.io/svgbob-editor/)
- [README](https://github.com/ivanceras/svgbob/blob/master/README.md)
- [Releases](https://github.com/ivanceras/svgbob/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ivanceras-svgbob