Turn mermaid code to diagram output without a local install

Getting mermaid code to diagram form means taking a snippet you already have and getting a picture out of it. Paste the text, fix the line that actually failed, and export only when some other tool needs a file.

I do this in the browser. The editor is free and it doesn't ask for an account. The preview is the picture. The snippet stays the source. This isn't a homepage tour, and it isn't a reason to install Node before you've seen whether the text parses. If you only wanted to look, and you don't intend to fix anything, the notes on how to view Mermaid diagrams online are the shorter version of the same first step.

The failures I care about are the ones that show up on real snippets: a missing end, a label that needed quotes, and a node whose id is the word end. After those, the plan limits on PNG, SVG, and PDF matter, because a green preview is not the same thing as the file someone asked you to attach.

From the snippet to the picture

Start with the diagram, not the markdown around it. If you copied a fence, delete the fence line and the closing backticks. The first line the preview should see is the keyword: flowchart, sequenceDiagram, or whichever type the snippet claims to be. A sentence above that keyword is prose. Move it out.

Paste into the editor. Look at the preview before you reformat anything. A snippet that renders is done, for the viewing half of the job. A snippet that errors is a line number, not an invitation to redraw the chart from the ticket description. I have redrawn from memory and "fixed" a policy the author had written correctly, except for one quote. The quote was the bug. The policy was fine.

Keep the ids. If the snippet uses n1 and n2, leave them until it renders. Renaming while you're repairing mixes a refactor into a bugfix, and the next error might be one you introduced. After it renders, rename if the ids are awful and you intend to keep the file. If you're only producing a picture for a slide, don't rename. You're not the maintainer of a slide.

The format of a Mermaid block is worth ten minutes if the snippet arrived inside a bigger markdown file and you're not sure what to strip. The syntax that stays true across diagram types is the page for the rules, once a specific error isn't enough and you want the pattern. This page is the path from a broken paste to a file you can hand someone.

The errors that actually stop the render

The syntax error guide is the catalog. Three of those errors account for most of the snippets people paste at me. I'll show the broken form as text, and the repaired form as a diagram, so this page itself still renders.

A missing closer. You opened a subgraph, an alt, or a loop, and you didn't finish it. The message often points past the hole, at the next keyword that no longer makes sense. Count the openers. subgraph needs end. alt needs end. loop needs end. An else only belongs inside an alt you already opened. I fix the closer before I touch labels. Labels are not why the block fell over.

An unquoted label. Parentheses, brackets, and some punctuation belong to the shape syntax. fee[Fee (USD)] looks like a rectangle with a parenthetical, and the parser sees a shape it can't finish. The repair is fee["Fee (USD)"]. Quotes are the label. The brackets are still the rectangle. I quote any label I didn't type myself once it contains anything but letters, numbers, and spaces. That's stricter than the language requires, and it survives the next edit.

The word end used as an id. end[Done] does not name a box called Done. end closes the subgraph you may not have noticed you were in, or it fails because nothing was open. The last step wants a different id. done([Done]) or stop([Stop]) draws a terminator without stealing the keyword. I grep for a node named end the way I grep for a bad merge. It's a one-word bug with a long diagram attached.

Other errors happen. A missing colon on a sequence message. A smart quote from a chat app. A flowchart arrow pasted into a sequence. Those are real, and they're in the guide. The three above are the ones I can spot without reading the message carefully, which is exactly when I should still read the message. The line number is faster than my memory of the usual bugs.

A missing closer, repaired

Someone sends this and says the preview died on the last line:

flowchart TD
    subgraph Intake
      ask[Request] --> gate{Approved?}
    ask -->|Yes| go[Continue]

The subgraph never closed, so the line after it is still inside a block that doesn't end, and the file ends instead. The repair is one word in the right place, plus the no branch they also forgot. Forgetting the no branch isn't a parse error. It's a policy error. I fix the parse first, then I look at the policy.

flowchart TD
    subgraph Intake
        ask[Request] --> gate{Approved?}
    end
    gate -->|Yes| go[Continue]
    gate -->|No| stop([Stop])

end here is the closer. It sits under the subgraph, not as a box. stop is the box. Both can exist in one file, which is the point of not naming the box end. The yes path leaves the group and continues. The no path stops. If you wanted the decision inside the group visually, put go and stop inside too, and close after them. Don't close early and also leave arrows outside unless the outside is intentional. I read the indent, but Mermaid doesn't use that indent for flowcharts the way a mind map uses indent. The end is the structure. The indent is for me.

If the error says the problem is go[Continue] and that line looks fine, believe that the bug is above it. Closers fail late. I scroll up for subgraph, alt, or loop before I rewrite go.

Quotes, then a node that must not be called end

The next snippet fails as soon as the fee label grows a parenthetical. Broken form: fee[Fee (USD)] --> tax[Tax]. Repaired, and with a terminator that is not named end:

flowchart LR
    cart[Cart] --> fee["Fee (USD)"]
    fee --> tax["Tax (local)"]
    tax --> done([Done])

LR because this one is a pipeline, not a decision. The quotes are doing the work on both labels. done is the id, and the label says Done, which is what the author was reaching for when they typed end. I left the amounts out. A label of fee["Fee (USD 2.50)"] is legal and brittle. The number will change, the diagram won't, and you'll have a confident wrong fee in the README. Put the number in the pricing table. Let the box say what the step is.

Direction and quotes don't interact. People "fix" a parse error by flipping TD to LR because the error happened to show up after they changed direction. Direction is not a syntax repair. Put it back to the reading order you wanted after the quotes are in. How rendering works is the page if the preview's behavior, rather than the source, is what seems off. A direction change that "fixes" a parse is a coincidence. Don't ship the coincidence.

A sequence that needs its closer and its colons

Sequence snippets fail on the colon and on alt more often than they fail on the arrow style. Broken message: App->>Hook Deliver. Broken block: an alt with no end. The repaired delivery is short on purpose. A webhook either gets a 2xx or it doesn't, and the retry is a loop with a closer of its own.

sequenceDiagram
    autonumber
    participant App as App
    participant Hook as Hook
    App->>Hook: Deliver the event
    alt accepted
        Hook-->>App: 2xx
    else rejected
        Hook-->>App: 4xx
        loop retry
            App->>Hook: Deliver again
            Hook-->>App: Still failing
        end
    end

Count the closers. The loop opens inside the else, so it closes before the alt closes. Two end lines, two openers. Reverse them and the inner end will close the alt early, and the outer end will be a stray. The preview's complaint will sound like a mystery. The structure is a stack. I close the inner block first, the same way I close a parenthesis.

autonumber is so a comment can say "step 3" and mean the 4xx. I don't also write "3." in the message. Participants are declared first so Hook doesn't appear on the left just because a note mentioned it early. Solid arrows go out. Dotted arrows come back. If your snippet uses solid arrows for everything, it may still parse, and it will read as all requests. I change replies to dotted after the parse is green, not before. One kind of fix at a time.

The message text stays short. "Deliver the event" is enough. The JSON body belongs in the doc, or the lifelines spread apart until the picture is a very expensive way to show a payload. I've reviewed that picture. I asked the author to delete the payload from the arrow and put it in a sample request underneath. The sequence got readable in one edit.

Which file you can download

A rendered preview is available while you edit. A download is a separate step, and the format depends on the plan.

PNG works on every plan. Free PNG is 1x and carries a small watermark. Starter is $6.99 a month and includes watermark-free PNG up to 4x. JPG, SVG, and PDF are Pro-only, and Pro is $11.99 a month. I say the numbers because "export" gets treated as one feature. It isn't. The PNG converter is the path for a ticket, a slide, or a doc that only accepts an image. The SVG converter is the path when the picture will be scaled, and only on Pro. The export guide covers what those files do after they leave the editor. I'm not repeating that guide. I'm telling you not to promise an SVG from a free preview.

I export PNG when the destination can't read Mermaid. I don't export PNG as the thing I commit, unless the repo's docs build can't render a fence and someone has already lost that argument. Even then I commit the source beside the image. A PNG of a diagram is pixels. The next label change is a redraw, and the diff is a blob. I have approved that blob. It taught me nothing about the change.

Scale is a multiplier on pixels. I don't take 4x by habit. I take the smallest scale that stays sharp in the place it will be seen, and I look at the file size before I attach it to a thread. A watermarked 1x PNG is fine for an internal "does this match the snippet" check. It is the wrong attachment for a customer. If you can't put Starter or Pro on the export, send the source.

JPG is on Pro, with SVG and PDF. I almost never want JPG for a diagram. Blocks of flat color compress badly, and the text goes soft. I mention it so you don't hunt for it on the free plan. It isn't there. PDF is the one I use when someone will print the picture or drop it in a packet. SVG is the one I use when the picture will live on a web page and should stay sharp. PNG is the default for everything else.

Keep the source next to the export

The diagram you hand over should have a parent. The parent is the snippet in git, or the markdown file the snippet was copied from. If you paste, fix, export, and close the tab, you have created an orphan image. The next person will redraw it, and they will not match your fixes.

I leave a one-line note above the fence: what broke, if it wasn't obvious, and which file the PNG was copied into. "Quoted the fee label. PNG attached to the incident ticket." That's enough. A paragraph about the nature of diagrams is not. A render walkthrough can wait until someone asks why the preview and the CLI disagree. When they disagree, compare the text first, including quotes you can't see, and don't assume the CLI is the truth just because it has a command.

If the snippet uses a diagram type you don't want to learn today, don't convert it during the export. A sequence that you flatten into a flowchart so the PNG "fits the slide" is a different design. Export the sequence, or change the design in a review where someone can argue. I've squeezed a sequence into boxes for a slide and lost the reply. The slide looked clean. The on-call engineer trusted it. The reply was the part that mattered.

Share links are fine for "open this text." They are not a substitute for the file if the diagram is part of the system. I use a share link when a teammate is away from the repo and we need the same preview for ten minutes. Then I put the repaired text back in the branch.

Paste the snippet into the editor, repair one error, and look again before you export. If the preview is green and the sentence it says is the sentence you meant, then pick PNG or a Pro format. If the sentence is wrong, a sharper export will only distribute it faster.