The diagram arrived as an SVG, but nobody can tell which text produced its arrows. Keep the DOT source beside the rendered SVG and check the node and edge labels against that source. A clean layout does not establish that the diagram contains the intended relationships.
Use a fictional handoff with three stages: Draft, Review, and Package. Draft points to Review, and Review points to Package. Those are the only two relationships in this exercise. The diagram describes a proposed document handoff; it does not track a real review or submit a package.
Open the complete example · Download the full HTML source
Give the renderer a small, explicit graph
digraph handoff {
rankdir=LR;
node [shape=box];
draft [label="Draft"];
review [label="Review"];
package [label="Package"];
draft -> review;
review -> package;
}
The Graphviz SVG output reference documents SVG as an output format. For a command-line Graphviz installation, the output choice is -Tsvg. The browser alternative used here is a WebAssembly build of Graphviz, rather than a claim that the desktop dot executable ran.
The Viz.js API documents the asynchronous Viz.instance() initialization and the instance's renderSVGElement() method. Load the chosen browser distribution first, then render the supplied DOT:
const graphviz = await Viz.instance();
const svg = graphviz.renderSVGElement(dotSource);
document.querySelector('#diagram').replaceChildren(svg);
The surrounding page must supply dotSource and the diagram container. Keep the library version with the source so a later review can reproduce the selected renderer. Do not call a page self-contained while it still fetches the library from a remote script address.
Check the relationships independently of the layout
Require three labeled nodes and two edges. Compare each edge's endpoints with the source: Draft to Review, then Review to Package. A graph with an extra Draft-to-Package edge may look reasonable while skipping the intended review step.
Node position is a layout result; edge direction carries the supplied relationship. Read the arrowheads and labels instead of inferring sequence solely from the left-to-right arrangement. If your source represents something other than sequence, state that meaning beside the graph.
Keep a plain-language description under the visual: “Draft goes to Review. Review goes to Package.” That gives the reader another way to inspect this tiny fixture and makes the intended relationships explicit without requiring them to read DOT syntax.
Fit the SVG into a reading page
Keep the generated SVG's view box and constrain its displayed width to the available column. Check the three labels at phone width; shrinking a large graph until its text is unreadable is not a useful handoff. For a larger real diagram, provide a readable overview and the original vector file rather than forcing every node into a narrow screenshot.
The existing SVG hosting guide covers a different step: how a vector file is served and embedded. Here the source-to-output check happens before delivery. Preserve the generated SVG and DOT together, then inspect the delivered page to confirm that all three labels and both arrow directions remain visible.
If you change a node or edge, regenerate from the maintained DOT. Editing only the SVG's visible text creates two competing versions. Finish the handoff with the source graph, its rendered output, and the short relationship description that the reviewer actually approved.
Download the maintained source and actual output archive. This archive retains the supplied fixture and the original generated files beside the reading copy.