FAQ

Click Copy share URL in the toolbar. The URL contains your diagram, compressed into the URL fragment (the part after #). Paste it anywhere — Slack, a PR comment, an email — and the recipient will land on the preview page with your diagram already rendered.

Because the diagram lives in the fragment, it is not sent to our server when the recipient opens the link. Their browser handles the fragment locally.

If your diagram is long enough that the URL gets cut off in chat clients, copy the SVG instead and attach the file. We are tracking shorter share links as a future feature.

Two common causes:

1. Very wide diagrams — switch the direction. flowchart LR produces left-to-right output that often fits a desktop screen better than flowchart TD.
2. Very tall diagrams — the preview pane scrolls, so the bottom of the SVG should be reachable. If it is not, try the SVG download button and open the file directly; the file is the full diagram.

If the rendered SVG itself is missing pieces (for example, edges that should connect two nodes are missing), check that the source has no typos around node names. Mermaid silently drops references to nodes it never saw declared.

The most common causes, in order:

1. Wrong diagram-type keyword on the first non-blank line. It must be one of flowchart, sequenceDiagram, classDiagram, stateDiagram-v2, erDiagram, gantt, pie, mindmap, journey, gitGraph, or timeline. A typo (flowchat) silently fails.
2. Missing direction after flowchart. flowchart alone errors; flowchart TD works.
3. Smart quotes from a copy-paste through a word processor. Replace " " ' ' with the plain ASCII versions.
4. Special characters in node labels. Wrap labels with parentheses, colons, brackets, or pipes in double quotes: A["Step (1): more"].
5. Wrong arrow grammar for the diagram type. Sequence diagrams use ->> and -->>; flowcharts use --> and -.->. Mixing them produces lexical errors.

The status bar below the editor shows the first line of the parser error. We have a longer troubleshooting guide with the ten most common errors and their fixes.

If a diagram renders here but not in your destination tool (GitHub, Notion, etc.), the cause is usually a Mermaid version mismatch — see the FAQ on Mermaid version above.

Yes. The preview tool is responsive: on screens narrower than ~820 pixels, the editor and the rendered diagram stack vertically instead of sitting side-by-side. You can paste a Mermaid block into the editor on a phone, see the rendering, and copy the SVG out — all from a mobile browser.

There are caveats:

• The on-screen keyboard takes up half the viewport, so the rendered diagram pane will be small when you are actively typing. Tap outside the textarea to dismiss the keyboard and see the full preview.
• Keyboard shortcuts don’t apply on mobile. Use the toolbar buttons.
• Very large diagrams that stutter on a laptop will stutter worse on a phone. If you are working on a 1,000-node diagram, draft on a desktop.

For pure viewing — opening a share URL someone sent you — mobile works well. The diagram fits the screen, and pinch-to-zoom is available where the SVG overflows.

No. Rendering happens in your browser using the bundled Mermaid library. The diagram source you paste is never sent to our server.

The “Copy share URL” feature uses the URL fragment (after #), which by web standards is not transmitted in HTTP requests. Even when someone follows the share link, our server does not see the diagram source — only the path /preview/.

For full details see the Privacy Policy.

Once the page has loaded once, the rendering itself works without an internet connection — the Mermaid library is bundled into the page, not fetched at runtime. If you load the preview while online and then go offline, you can keep typing and the diagram will keep rendering.

However, the page itself is loaded over HTTPS from our server, so the very first visit needs an internet connection. The site is a static Astro build with no service worker, so a hard reload while offline will fail.

If you want a fully-offline workflow:

• Use the mermaid npm package in a local Node project, or
• Use a tool like Obsidian or VS Code with a Mermaid extension that ships its own copy of the library.

Both approaches give you offline rendering at the cost of a setup step. For ad-hoc diagram drafting on a flight, opening this site once before takeoff and keeping the tab open works for most flights.

Ads pay for the server bill, the domain, and the time it takes to write the guides. The site is free to use because of them.

The preview tool itself is designed to keep ads out of the first fold — you should not see an ad above the editor on a normal-size laptop screen. If you do, it’s a bug; please tell us.

You are welcome to use a content blocker, and the site will keep working. Mermaid renders entirely in your browser; nothing on this site requires the ad scripts to load.

Mermaid Preview bundles Mermaid version 11, pinned in package.json. Each build of the site embeds the exact version, so what you render here matches what you would get from a fresh npm install mermaid@11.

GitHub’s renderer currently tracks Mermaid v10, and tools like Notion and GitBook track somewhat older versions. Most syntax is identical across these versions, but a few v11-only features (notably newer diagram types and some directive options) will not render on platforms still on v10.

When you copy a diagram from this preview into another tool and the rendering differs, version skew is the most likely cause. We document the practical consequences in our embed guides for GitHub, Notion, and the major static-site generators.

There is no hard upper bound. The practical limits are set by your browser:

• Up to ~500 nodes renders fast (under one second on a modern laptop).
• 500–2,000 nodes noticeably slows down — the main thread blocks for a fraction of a second on each render. Usable, but consider whether the diagram is communicating one thing or trying to communicate ten.
• Beyond ~5,000 nodes the browser may stutter or run out of memory.

If your diagram is genuinely that large, the more honest fix is splitting it. A 2,000-node diagram is rarely readable as a single image; it is almost always two or three smaller diagrams stacked together.

For the rare case where the diagram is genuinely needed in one piece — large org charts, generated dependency graphs — we are tracking server-side rendering as a future feature. It will lift the browser-memory ceiling at the cost of needing to send the diagram to a server (with explicit consent).

The PNG download button currently exports at 2× the on-screen resolution, which is fine for most documentation, web pages, and standard slide decks. For 4K or higher, two paths work:

1. Export the SVG instead. SVG is vector — it scales to any size without losing quality. If your destination accepts SVG (most do, including modern Keynote, PowerPoint, and Google Slides as embedded images), this is the right answer.
2. Wait for the higher-resolution PNG export. A configurable scale (1× / 2× / 3×) is on our roadmap and will land in a Phase 2 release.

For posters, prints, or other unusually large outputs, SVG is the only durable answer — even a 4× PNG looks soft when blown up to A1.