Which Graphviz output format should I share?

SVG. `dot -Tsvg` keeps every node label as real text, so the reader can Ctrl-F for a package name in a 400-node dependency graph. PNG turns all of that into pixels.

How do I share a .dot file with someone who doesn't have Graphviz?

Don't. Render it yourself and publish the SVG inside a page — the reader gets a URL and needs nothing installed.

My graph is enormous. What do I do?

Publish it anyway and wrap the SVG in a scrolling container. A browser handles a wide SVG better than any image viewer, and Ctrl-F still works, which is how people actually navigate a large graph.

Can I generate and publish this from CI?

Yes, and a dependency graph is a good candidate — regenerate on every merge to main and update the same report, so the graph is never stale.

Does this work for pprof and profiling call graphs?

Yes. Anything that emits DOT — go tool pprof, madge, pydeps, jdeps — renders the same way.

Share a Graphviz diagram

dot -Tsvg deps.dot -o deps.svg finishes in a second and produces exactly what you wanted: the dependency graph, laid out properly, every edge accounted for.

Now send it to the person who asked why the build takes eleven minutes. You have an SVG file, and a file is not a link.

Use SVG, and mean it

The format choice is not cosmetic here. Graphviz graphs are usually large and text-dense — package names, function symbols, module paths — and the reader's first action is almost always to look for one specific node.

-Tsvg keeps labels as text. Ctrl-F finds libcrypto. Zoom stays sharp.
-Tpng makes all of that unsearchable, and at the width of a real dependency graph the labels are unreadable at fit-to-screen.

dot -Tsvg deps.dot -o deps.svg

Publish it inside a page

Inline the SVG into a small document and publish that:

<!doctype html>
<meta charset="utf-8" />
<title>Build dependency graph — main</title>
<style>
  .scroll { overflow: auto; max-width: 100%; }
</style>
<h1>Build dependency graph</h1>
<p>Generated from <code>main</code>. Red edges are cycles.</p>
<div class="scroll"><!-- deps.svg inlined --></div>

The scroll container is the detail people forget. A dependency graph is often six thousand pixels wide, and without overflow: auto it either overflows the page or gets squashed into illegibility.

Inlining rather than linking keeps it one self-contained file — a separate deps.svg alongside is the missing-sibling problem behind HTML reports that lose their CSS.

Regenerate it in CI

A dependency graph is only interesting when it is current, and the honest lifespan of a hand-generated one is about a week.

Render it in the pipeline and update the same report on every merge:

- run: dot -Tsvg build/deps.dot -o build/deps.svg
- run: ./scripts/publish.sh build/deps.svg

One permanent URL that always shows main, instead of an artifact that expires and a Slack thread full of dead links. See publishing from CI.

Anything that emits DOT

The same path works for the tools that use Graphviz as a backend rather than as a diagramming language:

go tool pprof -dot — call graphs from a profile
madge, dependency-cruiser — JavaScript module graphs (see sharing a dependency-cruiser report)
pydeps, jdeps — Python and JVM dependencies
terraform graph — resource dependency graphs

Render to SVG, publish, share the URL.

Worth knowing

rankdir=LR for deep graphs. Vertical layouts get impossibly tall; browsers scroll horizontally better than they scroll a 20,000px page.
Comments anchor to the graph, so "this edge shouldn't exist" lands on the diagram — see commenting on HTML.
5 MB per report body. Even large SVG graphs fit comfortably.

Try it

Free — unlimited reports, commenters and revisions.

Publish a diagram →