My architecture diagram is generated by Claude Code with D3.js. Will the animations work?

Yes. display.dev serves the full HTML file including all inlined JavaScript. D3 animations, event handlers, and dynamic rendering all run as if the file were served from any web server.

What if the diagram has external JavaScript dependencies?

Self-contained HTML files (all JS inlined or loaded from public CDNs like `cdn.jsdelivr.net`) work with zero configuration. If the diagram references local JS files in a separate directory, publish the whole directory: `dsp publish ./diagram-dir/ --company`.

Can I embed a display.dev artifact in Confluence or Notion?

Not as an iframe, since Confluence and Notion restrict iframe sources. But you can link to the display.dev URL from any page, and the link opens the full interactive diagram in a new browser tab.

Who can see the diagram once it's published?

By default, anyone with an email on your company domain, after they authenticate. On Pro you can also restrict an artifact to specific invited people, or make it public if it's meant for a wider audience. Access is per-artifact and changeable any time.

Does the link keep working after I update the architecture?

Yes. Republish with `--id` and the URL stays the same while the content updates. Viewers who bookmarked it always land on the current version.

Share Interactive Architecture Diagrams With Your Team

Claude Code, Cursor, and other AI tools generate architecture diagrams as self-contained HTML files built on D3.js, Mermaid, or custom SVG and JavaScript. On your machine the diagram is interactive. The moment you try to share it, the interactivity is what you lose.

What you're losing with screenshots

An interactive architecture diagram has properties a screenshot destroys:

Hover tooltips showing component descriptions, dependencies, and metadata
Click interactions for drilling into subsystems or expanding details
Zoom and pan for navigating a large system without losing your place
Animated transitions showing data flows and request paths
Collapsible nodes for managing complexity in a big architecture

A screenshot of an interactive diagram is a static image of an application. The information it carries is a fraction of the original, and it goes stale the moment the architecture changes.

One command

dsp publish ./architecture.html --company --name "system-architecture"

Your PM, VP, and the security lead click the URL, sign in with their company Google or Microsoft account (or a one-time password on the Free plan), and see the full interactive diagram, not a JPEG approximation of it. Every hover, click, and zoom that worked locally works at the URL.

Common tools and their output

Tool	Output	Command
Claude Code (D3/Mermaid)	`./architecture.html`	`dsp publish ./architecture.html --company`
Mermaid CLI	`./diagram.html`	`dsp publish ./diagram.html --company`
draw.io HTML export	`./diagram.html`	`dsp publish ./diagram.html --company`
Structurizr Lite	`./site/`	`dsp publish ./site/ --company`
Excalidraw HTML export	`./drawing.html`	`dsp publish ./drawing.html --company`

When the diagram changes

Architecture is never done, so you want one URL that always shows the current version, not a fresh link every revision.

BASE_VERSION=$(dsp get-metadata 8f3kx9 | jq -r .currentVersion)
dsp publish ./architecture.html --company --id 8f3kx9 --base-version "$BASE_VERSION"

--id <shortId> is the update path: same URL, new content. --base-version tells display.dev which version you edited from, so a teammate's newer publish can't be overwritten silently. Publishing again without --id creates a fresh artifact with a new URL, which is rarely what you want when the diagram should stay current at one address. Grab the shortId from the first publish and update in place. Each revision is kept as a version in history: 10 versions on Solo, 50 on Pro.

Why this matters for architecture specifically

Architecture diagrams are read by more people than almost any other engineering artifact: the on-call engineer at 2am, the new hire in week one, the security reviewer, the VP deciding whether to fund the migration. Diagram-as-code tools like Mermaid exist precisely so the picture stays in sync with reality. Publishing to a URL that updates in place finishes that job: the diagram is versioned, current, and readable by non-engineers without a checkout, a build step, or a screenshot that's already wrong.

Getting an interactive diagram out of Claude Code

If you're starting from a description rather than an existing file, ask for a self-contained artifact so it publishes with zero configuration. A prompt like:

"Generate an interactive architecture diagram of this system as a single self-contained HTML file. Use Mermaid or D3. Inline all CSS and JavaScript, or load libraries from a public CDN. Add hover tooltips for each component and click-to-expand for subsystems."

produces one .html file with everything inlined. That's exactly the shape dsp publish ./architecture.html --company wants. If the agent splits assets across files, either ask it to inline them or publish the whole directory with dsp publish ./diagram-dir/ --company. The same approach works from Cursor or Codex, since dsp publish doesn't care what wrote the file.