DiagramPreview
Basic parserD2ArchitecturePreview workspace

D2 Preview

Draft D2 diagram text in the shared DiagramPreview workspace while the dedicated renderer is prepared.

Examples
D2 previewReady
The D2 preview renderer is coming online.

Continue with a related tool

Move this preview into a nearby workflow for conversion, debugging, or export.

How to use

  1. 1Paste D2 text into the editor and start with relationships before styling.
  2. 2Use samples to structure service maps, deployment zones, or architecture notes.
  3. 3Keep identifiers stable so future edits do not unexpectedly reshape the diagram.
  4. 4Write edge labels as protocols, events, or verbs when the relationship is not obvious.
  5. 5Return after the renderer module is enabled for SVG output.

Common use cases

Architecture sketchesService mapsSystem diagramsDependency reviewDeployment zone diagramsText-first architecture docs

FAQ

Is D2 rendering enabled?

The route and workspace are ready. The dedicated renderer is planned for the next build stage.

What makes a D2 diagram easier to review?

Stable node ids, short edge labels, nested containers for boundaries, and comments for assumptions make D2 diagrams easier to maintain as text.

When should I use D2 instead of Mermaid?

Use D2 when you want text-first architecture diagrams with explicit containers, labels, and layout-friendly service relationships.

D2 Preview is prepared as part of the DiagramPreview tool family so D2 diagrams can share the same editor, metadata, export patterns, and related tool navigation.

The first build wires the page into the site structure and sample system. A dedicated renderer can be added behind the same workspace without changing the public URL.

This page is intended for architecture sketches, service maps, and text-first system diagrams.

Demo: draft a D2 service map

D2 is readable for architecture diagrams that need labels, containers, and typed relationships. Even before final styling, a preview helps verify that the text describes the intended system.

  • Use nested blocks for domains or deployment zones.
  • Write relationship labels as verbs or protocols.
  • Keep identifiers stable so future edits do not reshuffle the whole diagram.
client -> gateway: HTTPS
gateway -> orders: REST
orders -> queue: publish event
queue -> worker: consume
orders -> db: SQL

Review note: separate structure from visual polish

The best D2 workflow starts with structure. Once nodes and edges are correct, apply themes and layout settings; otherwise styling can hide that the diagram is missing an important dependency.

  • Validate the graph in plain form first.
  • Only add icons or custom styles after the flow is correct.
  • Use comments to explain assumptions that are not visible in the graph.
# Assumption: analytics is async
api -> event_bus: order.created
event_bus -> analytics: consume

Architecture note: model boundaries before dependencies

D2 is useful for showing bounded contexts, deployment zones, and ownership boundaries. Start by modeling containers and then add dependencies inside or across those boundaries.

  • Use nested blocks for teams, networks, or runtime zones.
  • Name external dependencies explicitly so they are not mistaken for internal services.
  • Keep async and sync relationships visually distinguishable through labels.
prod: {
  web
  api
  worker
}
external: {
  stripe
}
web -> api: HTTPS
api -> stripe: payment auth
api -> worker: order.created

Review checklist for D2 Preview

Use D2 Preview when you need to inspect source content visually before it becomes documentation, a pull request note, an incident write-up, or a handoff artifact. Preview D2 architecture diagrams and service maps in a focused workspace.

Before exporting, check that labels are readable, relationships match the source, generated examples do not contain private data, and the preview still makes sense after you edit the input.

Limits and troubleshooting

If the preview fails, reduce the input to the smallest complete example, confirm the format syntax, and then add sections back one at a time. Many rendering failures come from partial files, indentation mistakes, missing diagram headers, or copied snippets that depend on hidden context.

Treat the preview as a review surface rather than a source of truth. Generated diagrams, converted files, dashboards, and rule examples should be checked before they are used in production documentation or operations.

Example inputs to test

  • Architecture: client -> gateway -> api api -> database api -> queue
  • Service map: web: Web app api: API service db: Database web -> api -> db
  • Sequence: user -> app: request app -> api: fetch api -> app: response

Tool maturity

Basic parser

Basic parser

This tool focuses on fast structure inspection. Use it for review and debugging, then verify critical output before production use.

The maturity label is not a quality score. It tells visitors whether the tool is best for stable export, deeper debugging, quick parsing, or AI-assisted generation.