Exporting

Everything sits behind the Export ▾ button in the toolbar. The popover has two shared options at the top, then the formats.

Shared options

Theme — Match app (default), Light or Dark. This decides which colour tokens are baked into the exported file, independently of the theme you are editing in: you can work in dark mode and export a light diagram for documentation.

Transparent background — drops the paper fill so whatever the file is placed on shows through.

Three further things follow what you are looking at rather than being options. Hidden layers are never exported — a layer you turned off cannot be revealed by a recipient. The View menu travels with the picture: switch off the port labels, the zones or the connectors and SVG, PNG, copy-image, HTML and PDF give you the drawing as you are seeing it, while the data exports (the CSVs, DOT, Mermaid, Containerlab) still carry everything on the page. And if the canvas is in isometric view, those same five export the isometric projection from the corner you have orbited to.

Exports are named after the active page's name — the one on its tab in the pages bar (name.svg, name.png, name-inventory.csv); the HTML viewer, being a whole-document file, is named after the open file instead. In the desktop app you pick a destination and get a toast naming the path; in the browser it arrives as a download.

The document's own title is the open file's name without its extension — campus.drawio is titled "campus" — and Untitled until the document has been saved to a file. It is one rule everywhere a whole document is named: the printed sheets' title block, the PDF, the printed cable schedule and its labels, and the HTML viewer. A page's name never stands in for it, however many pages the document has and whichever one you are looking at. Give the document a title of its own — and an author and a revision — under Document info…, and that title leads instead.

SVG

Export → SVG writes a standalone .svg of the active page. Styles and design tokens are inlined, so the file is faithful on its own and makes no network requests.

PNG

Export → PNG writes a .png of the active page rendered at 2×, so it stays sharp in documents and slide decks. It is rasterised from the same SVG the SVG export produces.

Copy image

Export → Copy image puts the same 2× PNG on the system clipboard instead of writing a file — paste it straight into a ticket, chat or document. It honours the theme and transparency options.

If the page is empty, or the browser does not support writing images to the clipboard, you get a message saying so rather than a silent failure. Clipboard writes also fail if the window is not focused.

Visio (.vsdx)

Export → Visio writes the whole document — all pages — as a .vsdx, independent of whatever file the document is open from. This is the path that works everywhere; the Save dialog only offers .vsdx where the browser's file-picker API is available.

Pages you have not visited are exported too, and routed first, exactly as opening them would route them — so a cable on a page you never looked at still goes round what stands in its way. The PDF book and the HTML viewer do the same. On a document with many large pages you have not opened, that can add a moment before the file appears.

PDF

Export → PDF exports the whole document — one sheet per page, in tab order — through the browser's print-to-PDF: a print document is assembled and the print dialog opens, where you choose "Save as PDF". It needs no plugin and works the same in the browser and the desktop app. Want just one page? The print dialog's own Pages field already does that (the sheets are in tab order, so page 3 of the document is page 3 of the print), which is why there is no extra choice to make here. An empty page adds no blank sheet.

• Paper is chosen for you — there is nothing to set. A page starts on A4, and if the drawing would have to shrink below half size to fit, it steps up to A3; if A3 is still too small it steps again, to A2 and then A1. A wall-sized DC floor plan or a forty-closet campus gets the plot it needs rather than being squeezed onto a sheet nobody can read. Small diagrams are enlarged to fill the page — it is vector, so it stays crisp.
• Portrait or landscape follows the drawing: a page that is taller than it is wide — a rack elevation, a stack of sites — prints portrait, and everything else prints landscape.
• Size is one for the whole document; orientation is per page. A single large page makes every sheet A2, rather than mixing sheet sizes in one stapled document — but a site pack still prints its wide campus map landscape and its tall rack elevation portrait, each the way you drew it.
• Title block along the bottom of the sheet: document title (the open file's name without its extension, or Untitled), that sheet's page name, the date (YYYY-MM-DD) and the Drawbridge version beside the Drawbridge mark — plus the author and the revision when Document info… names them. It grows with the paper, so it reads the same on an A1 plot as it does on A4. A page that already draws its own Blocks → Title block does not get the band as well: one title block to a sheet, and the one you placed on the page wins. See Title blocks.
• The sheet is always white, the diagram is drawn with no background fill, and it always prints the light colours — a PDF is ink on paper, not a screenshot of a dark canvas. The Theme option has no say here, deliberately: the dark colours on white paper are near-black tiles and cables you can barely see, so a PDF reads the same whichever theme you are in.
• A legend on the page is ordinary page content and is included automatically.
• Pages you have not visited are routed first, exactly as opening them would route them, so a cable on a sheet you never looked at still goes round what stands in its way. On a document with many large pages you have not opened, that can add a moment before the print dialog appears.

An empty page exports nothing.

PDF with schedules

Export → PDF with schedules is the same PDF with the paperwork after it: the drawing sheets exactly as above, then the cable schedule and then the inventory, in one file. It is the handover pack — the thing you print for commissioning, hand to the person doing the install and file with the site documentation — instead of exporting a PDF, opening two CSVs in a spreadsheet and stapling the result together.

• The cable schedule prints on A4 portrait, grouped by device the way the cable checklist groups it: one heading per device, one row per cable with the port you are in, where the other end goes, and an empty box to tick when it is in. Cables already ticked in the checklist print with the box filled.
• The inventory prints on A4 landscape — every device on every page with its asset data, the same columns as the CSV inventory.
• Both carry the same title block as the sheets, with the page name reading "Cable schedule" or "Inventory", so a page that gets separated from the pack still says what it belongs to.
• A section with nothing in it is left out. A document with no cables prints its sheets and its inventory, and nothing headed "Cable schedule".

There is nothing to choose: it is the whole document, always, and the print dialog's own Pages field still picks out the part you want. In Studio, the Pack view is the same file with choices — below.

The handover pack (Studio)

In Studio, press Pack at the top of the window to put the handover together: the drawings and the tables you choose, in one file, numbered and titled. Draw brings the drawing back.

• Sheets lists every page with the paper it will print on — "A3 landscape", say. The PDF picks one size for the whole document, large enough for the biggest page, and turns each sheet the way it is drawn; the label is that choice, not a guess. A page with nothing on it reads "nothing on it" and is left out.
• Tables lists the cable schedule, the inventory, the optics (the optics CSV's rows: what to fit on which device), the revision table (every saved revision, oldest first) and rack elevations (each rack as its rails read: one row per U, top first, each unit named in its top U and spanning its height, the front and, for a two-bay rack, the rear). Each says what it would hold; one with nothing to hold reads "none yet".
• Look says which watermark and classification the file will carry. They come from the page card's Branding, and a PDF is always ink on white paper.

The right-hand side numbers what the file will hold, in order: each ticked sheet the way round it prints, then each ticked table. A table flows onto as many A4 pages as it needs, so its card stands for its first page. As the view opens, every sheet, the cable schedule and the inventory are ticked — exactly PDF with schedules.

• Preview shows the pack as it will print, inside Drawbridge, before anything is saved: the drawing sheets as their paper, then each table on A4 (in the printed file a long table runs on over as many pages as it needs). Scroll through it, then press Save PDF or print… at its top to print exactly what you saw, or Close (or Esc) to go back and change the ticks.
• Save PDF or print… opens the print dialog with the pack: choose Save as PDF, or a printer.
• Save HTML viewer saves the HTML viewer of the ticked sheets.
• Share the schedule copies an install link for the cable schedule, as the schedule's own Share does; the button says Copied ✓.

Classic keeps the Export menu, and so does Studio: PDF and PDF with schedules are there in both.

HTML viewer

Export → HTML viewer writes the whole document as one self-contained .html file. It opens in any browser, offline, and can be emailed, attached to a ticket or committed next to the .drawio it came from — the answer to "I can't open your diagram".

It is genuinely self-contained: all CSS and JS inline, system fonts only, images as the data URLs already in the document, and zero network requests.

Pages you have not visited are routed before the file is written, exactly as opening them would route them, so a cable on a page you never looked at still goes round what stands in its way. On a document with many large pages you have not opened, that can add a moment before the file appears.

What the viewer adds over a flat picture — the things a PNG loses:

• page tabs for every page in the document;
• zoom in/out and Fit, with panning;
• layer toggles for the layers you published;
• a details panel showing a device's asset data, and a link to another page opens that page's tab.

Finding your way around a handover file

The file is the one the helpdesk, the auditor, the customer or the installer opens without the app, so it answers the questions they actually arrive with.

Search. The box in the toolbar looks through names, management IPs, serial numbers, models and locations across every page. The count beside it reads 2 / 7; Enter walks to the next answer and Shift+Enter back, each one scrolled into view and outlined while the rest of the drawing fades. A hit on another page switches to that page.

What is this connected to? Click a device and its cables and its neighbours light up, with a count. Click a second device and every equal-cost cabled way between them lights instead, each in its own colour, with the count and the hop length — "LEAF-01 → LEAF-04 · 2 paths · 2 hops". In a fabric that is one way per spine. It is the same walk the editor's Trace path does, and the same honest answer: "no cabled path" when the drawing does not show one.

Click either end again and the answer widens to the next length up — the longer ways round, for when you are looking for the backup rather than the obvious route. The status line says so while there are more to show. Clicking any other device starts a new question, and Escape puts the drawing back.

Folded groups. A group you collapsed arrives as one tile with its ×N marker, exactly as you left it. Click the tile — or Open groups in the toolbar — to see the devices inside; the button then offers the way back. Nothing in the file changes: it carries both pictures. Opening a group moves nothing else: every cable keeps the route it had, except one to a device inside the group, which is drawn straight to it.

The legend is a set of switches. Click a device kind in the legend to take those devices out of the picture, along with the cables that reach them; click a link type or a speed to take those cables out. Clicking the row again brings them back. It is a way to ask "show me only the fibre" without an editor, and it is per page.

The cable schedule is the last tab: every cable grouped by the device you stand in front of, with its ports, speed, cable type and label, and the installed ticks exactly as they were when you exported. It is read-only, and a snapshot — if someone needs to tick boxes as they work, send the share link instead.

The text is real text, so the browser's own find and print work on it too. With JavaScript disabled the pages simply stack vertically under their own headings, the tabs become anchors, and the layer toggles still work; the search box and the buttons above are simply not there.

All of this makes the file bigger than a plain viewer of the same document — roughly half as big again. When it matters the export toast tells you: HTML viewer · 1.8 MB.

CSV inventory

Export → CSV inventory writes every device on every page with its asset data, and then where it physically is: the Rack it is mounted in, the U it sits at — counted from the bottom, the way the rails are numbered — the innermost Zone or virtual context it stands in, whether it is Installed, and which Power feed a rack unit is on. A device standing loose leaves the rack columns empty; a device in no zone leaves that one empty, and a device nobody has ticked either way leaves Installed empty rather than guessing. See Inventory in Files and templates.

Optics CSV

Export → Optics CSV writes <title>-optics.csv: one row per part the document's cables call for — page, device, model, the part itself, how many, whether it is a transceiver, a cable assembly, a passive cable or not specified, and last a Note carrying the assumption behind that row's number where it has one (a copper run on SFP cages is counted at both ends, and a speed no BASE-T module is made at says so). It is the same count the Optics report in the app menu shows and the Blocks → Optics block puts on a page, as a file you can hand to purchasing. See Cable type, and how many transceivers you need.

A document whose cables need no hardware at all writes nothing and says so, rather than handing you a header row.

Copy Mermaid

Export → Copy Mermaid puts the active page on the clipboard as a fenced ```mermaid block, ready to paste into a markdown article, a README, a wiki page or anywhere else mermaid renders — GitHub and GitLab render it in place.

This is a topology export, not a picture of your layout: mermaid has no coordinates, so its renderer arranges the graph itself. What travels is what is connected to what — every device with its label, zones (and racks) as titled subgraphs holding whatever stands on them, and every link with its caption, port names and speed as the link's text. Dashed link types (IPsec, WAN, Mgmt, Wireless) come out dotted and heavy ones (Trunk, LAG, Conduit) come out thick, so the line language survives in spirit. A wide drawing flows left-to-right, a tall one top-to-bottom.

Free text, callouts, the legend and map or Purdue backdrops are presentation rather than topology and are not included; a hidden layer stays hidden, as in every export. The snippet carries no colours on purpose — it adopts the theme of wherever you paste it. If you want the diagram exactly as drawn, use SVG or PNG; Copy Mermaid is for when the article should own the drawing.

And it comes back. Beside each statement the snippet carries a %% fk: comment line holding what mermaid itself has nowhere to put — the shape kind, the role, the asset data, a zone's subnet, a cable's port names and speed and type. Every mermaid renderer ignores a comment, so the published diagram is unchanged by it; paste the block back into Import and you get the drawing back, icons and all, rather than a flowchart of grey boxes. Layout is the one thing that does not survive, because mermaid has no coordinates to write it in — the import lays the page out afresh. If you need the geometry too, use Graphviz DOT below.

Graphviz DOT, and Copy DOT

Export → Graphviz DOT writes the active page as a .dot file, and Export → Copy DOT puts exactly the same text on the clipboard. It is the way back out of the app for Diagrams from code: what leaves here is written in the same attribute profile the DOT import reads, so a drawing can go into a git repository, be reviewed as a diff, be edited or generated further by a script, and come back in through Import as a drawing. It is also ordinary Graphviz — dot -Tpng page.dot renders it in any Graphviz tool.

Unlike Copy Mermaid, this carries the layout too: every device writes its position and size in Graphviz's own pos=/width=/height= spelling, so importing your own export puts everything back exactly where it was — and a plain neato render shows your geometry, not a fresh one. What travels is most of the drawing:

• every device with its name, kind=, accent colour, asset fields (mgmtIp=, serial=, model=, location=, notes=), position, size, label placement, group membership and named layer;
• every link with its identity (id= — what keeps the two cables of an HA pair two cables), port labels, caption, speed=, link= type, aggregates (bundle=, whose ring captions ride along as the names), the sides it attaches to, and how it is drawn (router=, waypoints, arc bow, label placements);
• zones, virtual contexts and racks as subgraph cluster_… boxes carrying their kind=, name, cidr= and rect — they come back as real containers holding what stood on them;
• Purdue levels as clusters carrying purdue="N" — rebuilt at their recorded rect;
• free text and callouts (with their styling and leader), images, rack units, and the document's speed→colour overrides;
• devices drawn level with each other as {rank=same; …}, so an HA pair or an MCLAG peer pair returns side by side even in a file with no positions.

Two things are rewritten on the way out, both because the DOT profile identifies a device by its name. Arrows are written downwards — the device drawn higher is at the tail — because that is how the import reads tiers when a file carries no positions, and connectors are drawn without arrowheads here anyway. And two devices sharing a name are numbered (Switch, Switch 2); leaving them identical would merge them into one tile on the way back in, and losing a device is worse than gaining a suffix.

The legend (derived and regenerable) and map backdrops stay home, and hidden layers stay hidden — a layer you turned off cannot leave the app. A cable drawn to a zone keeps the zone as a plain node rather than a box, because DOT cannot attach an edge to a cluster — the cable matters more than the frame, and the zone still returns as a zone.

Containerlab YAML

Export → Containerlab YAML writes the active page as a <title>.clab.yml — the round-trip partner of the Containerlab import, and the entry that turns a design into something that boots.

Every device becomes a node under topology.nodes with the NOS kind its icon implies — an L3 switch and a plain switch both write nokia_srlinux, a router nokia_sros and a firewall fortinet_fortigate. Where the icon says nothing about the platform, the role band answers instead: CORE, DIST, ACCESS, TOR, SPINE, LEAF and MGMT write nokia_srlinux, and BORDER, PE and CE write nokia_sros, so a generic tile tagged SPINE boots as a fabric node rather than a bare container. Anything neither answers for is linux. Its management address becomes mgmt-ipv4, and the zone it stands in becomes group. Every cable that names an interface at both ends becomes a link in the brief form Containerlab's own examples use — endpoints: ["spine1:e1-1", "leaf1:eth1"].

Two things it will not do. It does not invent a port: a lab link is a wire between two named interfaces, so a cable missing a port label at either end is listed in a comment at the foot of the file rather than written with a made-up eth0 — fix the drawing or fix the file, but the file never claims something the drawing did not say. And it does not guess an image: the drawing names a platform, not a container image with a version that will be wrong by next quarter, so the file opens by telling you to add an image: to each node before containerlab deploy.

Device names travel as node names, so they are held to what a container name allows: spaces and punctuation become dashes, and two devices sharing a name are numbered. Free text, callouts, the legend and backdrops stay home, and hidden layers stay hidden.

Your own export imports back as the same topology. Two facts Containerlab's schema has nowhere to put — which icon a device was drawn with, and its role band — ride as node labels:, and only when they would otherwise be lost, so an ordinary topology of switches, routers and servers comes out with no labels at all and still returns as the devices it was, cabled port to port.

It is the topology, not the drawing: a lab file holds nodes, groups and wires and nothing else, so what it has no room for does not come back. The layout is laid out afresh on import, because there are no coordinates to read; a zone returns as a zone but without its subnet; and a cable returns as a plain connector — its link type, its speed and its label stay behind, as does every asset field except the management address. If you want the drawing itself back, round-trip it through Graphviz DOT above.

It is also --export dc.clab.yml from the command line and the API.

Cable schedule CSV, and NetBox

Three more entries in the Export menu turn the cabling and the hardware into a spreadsheet:

• Cable schedule CSV — one row per cable: page, both ends with their ports, speed, cable type, wavelength, link type, aggregate, label, whether it is ticked as installed, the VLAN it carries, the address at each end, the circuit and provider of a carrier-delivered link, Via — every device a run joined with Link as one cable passes through, each with the position it is patched to (PP-A:12, or PP-A:12/24 where it is cross-patched). Blank on every ordinary cable, which is every row in a drawing that has never joined one. See One row per run. Last comes Length, as you typed it — see Cable length. New columns are appended on the end, so a mapping you have already set up keeps working.
• NetBox cables CSV — the same cabling in NetBox's own cable bulk-import columns (side_a_device, side_a_type, side_a_name, side_b_*, type, status, label, length, length_unit), ready to paste into its import form. Cables you have ticked import as connected; the rest as planned.
• NetBox devices CSV — the hardware, in NetBox's device bulk-import columns: name, device_type, role, site, rack, position, face, serial, status. The Model asset field becomes device_type and the Location field becomes site; the role band becomes role, lower-cased to match NetBox's own naming; and a device mounted in a rack brings its rack, its U and which elevation it is on. status follows the Installed tick, the way the cables file follows the schedule's: a device you have marked planned imports as planned, and one you have ticked installed — or never ticked either way — as active. Import the devices first and the cables second — NetBox needs the boxes to exist before a cable can reach them.

Two things about the NetBox file are deliberate. Its type column is a closed list, so Multimode (SR) becomes mmf, everything single-mode (LR, ER, BiDi, CWDM, DWDM) becomes smf, and AOC becomes aoc — but five media are left blank. RJ45, RJ45 on SFP and DAC are blank because NetBox wants to know which of cat5e/cat6/cat6a it is, and whether a DAC is passive or active, and the drawing does not say — the BASE-T modules on an RJ45-on-SFP run are not a cable type, and the lead between them is the same unspecified twisted pair. Breakout DAC/AOC (4×) and MPO breakout (SR4 → 4×SR) are blank because NetBox has no breakout type at all — a breakout is four cables there and one row here, so any single value would be a wrong answer to a question the row cannot ask. A DCIM is a source of truth; a guessed value in one is worse than an empty cell somebody fills in.

And a cable terminates on an interface in NetBox, so a cable with no port name at one end will be rejected on import. The cable schedule panel tells you how many are in that state.

The devices file is deliberately nine columns rather than the thirty NetBox will accept: tenant, manufacturer, platform and the rest are not things the drawing knows, and a column of blanks is noise in an import form. face is written whenever a position is, including on a rack drawn with only a front elevation, because NetBox rejects a positioned device that does not say which side it is on.

Both files come back out of the CLI too, as --export plan.netbox.csv and --export plan.netbox-devices.csv.