# How to Share a PlantUML Diagram Without a Server (2026) Canonical: https://commareports.com/share-plantuml-diagram Published: 2026-09-14 > PlantUML renders to SVG on a server your reader can't reach, and the public encoder leaks your architecture. Publish the rendered SVG as a page and send a URL. # Share a PlantUML diagram You have `architecture.puml` in the repo, which is the right place for it: it diffs, it reviews, it lives next to the code it describes. Getting it in front of someone is the problem. Three bad options present themselves, and the most convenient one is the worst. ## The public server is a disclosure `plantuml.com/plantuml/svg/` is seductive — no setup, instant image. It also works by encoding your diagram source into the URL and sending it to a server you do not run. For a tutorial example, fine. For the diagram naming your internal services, your queue topology and `payments-db-prod.internal`, you have just published your architecture to a third party's access log and to whatever crawls the link. Most security reviews would catch this; most people never think to run one on a diagram. ## Render locally, publish the result Rendering is a local operation. Keep it that way: ```bash plantuml -tsvg architecture.puml # → architecture.svg ``` Then wrap the SVG in a page and publish it. The source never leaves your machine, and the reader gets an ordinary URL: ```html Service architecture

Service architecture

Source
``` Inlining the SVG rather than linking it keeps the page self-contained — a linked `architecture.svg` is the same missing-sibling-file problem that makes [a shared HTML report lose its CSS](/html-report-broken-css). ## Keep the source under the diagram The `
` block above is the habit worth forming. A reviewer who can see the `.puml` can tell you the arrow direction is wrong *in the source's terms*, which means the fix is a one-line diff rather than an interpretive exercise. It also makes the diagram honest about being generated. Nobody wonders whether the picture and the file have drifted, because both are on the page. ## From CI If the diagram is generated in a build, publish it in the same job: ```yaml - run: plantuml -tsvg docs/architecture.puml - run: ./scripts/publish-diagram.sh docs/architecture.svg ``` Updating the same report id on each run gives the architecture diagram one permanent address that always shows `main` — much better than a build artifact that [expires in ninety days](/fix/ci-artifact-expired). The general pattern is in [publishing from CI](/ci). ## Worth knowing - **`-tsvg`, not `-tpng`.** Selectable text, no blur, smaller file. - **`!include` resolves at render time.** Shared stylesheets and sprite libraries need to be reachable when you run the jar, not when someone opens the page. - **Comments anchor next to the diagram**, so "this dependency points the wrong way" lands where the arrow is — see [commenting on HTML](/comment-on-html). - **5 MB per report body.** ## Try it Free — unlimited reports, commenters and revisions. **[Publish a diagram →](/docs/quickstart)** ### Related - [Share a Mermaid diagram](/share-mermaid-diagram) · [Share a Graphviz diagram](/share-graphviz-diagram) - [Share a Structurizr C4 model](/share-structurizr-diagram) · [Share a draw.io diagram](/share-drawio-diagram) - [Publish from CI](/ci) · [Commenting on HTML](/comment-on-html)