How to view mermaid diagrams online, free and with no install

You can view mermaid diagrams online by pasting the source into a browser and reading the picture there. If the text already exists, you don't need Node, a package install, or a CLI on the machine you're sitting at.

I do this when a pull request touches a diagram and I want the picture before I clone. The source might be a fenced block in a README, a .mmd file, or a chunk someone pasted into chat. The job is the same. Get a preview, see if it parses, and export a PNG only when a tool that can't read Mermaid needs the pixels.

This is a working guide for that job. It isn't a product homepage, and it isn't a tour of every diagram type. If you want the longer path from a snippet to a file you keep, the notes on turning Mermaid code into a diagram pick up after the first successful render.

Paste the source, skip the install

Open the free editor. There's no signup. Paste the diagram text into the code pane. The preview updates in the browser. That's the whole install step, which is to say there isn't one.

Strip the markdown fence if you copied it. The preview wants the diagram, starting at flowchart or sequenceDiagram or whatever the first keyword is. A leading fence line is markdown. Leave it in and the first error will be nonsense, because the parser is trying to read backticks as a keyword.

If the snippet lives inside a larger markdown file, you don't have to extract it by hand every time. A markdown Mermaid viewer is built for a file that already has prose around the fence. Use that when you're checking a README. Use the editor when you expect to change a line and look again.

I keep a scratch buffer for viewing. If I'm only looking, I don't format the text, I don't rename ids, and I don't tidy someone else's style. Viewing is not editing. The moment I change an id, I'm on the hook for the diff, and I should be in the repo, not in a throwaway tab.

Copy from the file, not from a rendered HTML page, when you can. A rendered page sometimes turns quotes into curly quotes. Those look identical in a proportional font and they fail the parse. If the preview errors on a line that looks fine, paste the line into a hex-aware editor or just retype the quotes. I've burned a review cycle on a quote that wasn't the quote I thought I typed.

What shows up in the browser

The preview is the diagram the library draws from your text. Boxes, arrows, lifelines, and the layout the engine picked. It is not a screenshot someone uploaded. If you change a label, the picture changes. If the text doesn't parse, you get an error instead of a half-drawn chart. A half-drawn chart hides the broken line, and then you start "fixing" layout that was never drawn.

Live preview is the reason to do this in a browser. You shouldn't have to save, run a command, and open an image to see whether an arrow attached to the node you meant. I still run a CLI in CI when a repo wants committed images. I don't run it to answer "does this snippet draw?"

Themes and spacing can differ a little between tools. I don't treat pixel-perfect layout as part of the source. The source is the text. If a reviewer says the arrow looks different in their viewer, I ask whether the text is the same before I chase a layout bug. Layout is allowed to move when you add a node. Meaning isn't.

A share link is useful when the other person doesn't have the repo and you want them to open the same text. I still commit the diagram. A link is not a backup, and it isn't the review. The review should be able to quote a line. If your only artifact is a link to a session you might close, the next person inherits a picture they can't reconstruct.

Read the error before you rewrite the diagram

Most blank previews are one bad line. The message usually names that line. Go there. Don't retype the diagram from memory because the first line looks fine.

The syntax error guide walks the failures I hit most often. The short version, from diagrams I've broken myself:

• The fence, or a sentence of prose, is still at the top.
• A label has parentheses and isn't quoted, like fee[Fee (USD)].
• A node id is the word end, which closes a subgraph instead of naming a box.
• A subgraph or an alt was opened and never closed.
• A sequence message is missing the colon, so Shop->>Pay Charge never becomes a message.

Fix the line the error points at, then look again. If you change three other lines at the same time, you won't know which edit mattered. That's the same discipline as a compiler error. One change, then look at the preview.

I've lost twenty minutes rewriting a sequence diagram that only needed a colon. The arrows were fine. The parser was right to refuse the line. The embarrassing part was that I trusted my eyes over the message, because the line "looked like" the examples I'd seen. Looking-like is not parsing.

When the message is vague, I delete from the bottom until it renders, then add lines back one at a time. That's crude, and it works on a forty-line diagram. It works badly on a four-hundred-line diagram, which is a hint that the diagram should have been two diagrams. I don't binary-search a file that large in a browser tab and then paste the whole thing back into git. I split it first, in the repo, where the split is reviewable.

A checkout flowchart

Say the snippet in the ticket is a checkout policy. Under a limit, the order captures payment immediately. Over the limit, a reviewer has to approve it. Rejected orders stop. Approved ones capture. Here's text I'd paste, not a sketch of it.

flowchart TD
    start([Cart submitted]) --> total[Read the order total]
    total --> gate{Over the review limit?}
    gate -->|No| capture[Capture payment]
    gate -->|Yes| review[Reviewer checks the order]
    review -->|Approved| capture
    review -->|Rejected| hold[Leave the order unpaid]
    capture --> receipt@{ shape: doc, label: "Receipt" }

start is a stadium because it's a terminator, the point where this policy begins. I didn't name the last box end either. hold and receipt are the two ways out. The diamond is the only question. Both the "no" branch and the approved branch land on capture, which is the policy: two paths, one charge.

The document shape on the receipt is a nod to the old flowchart stencil. If a viewer complains about shape: doc, replace that line with receipt[Receipt] and move on. The policy doesn't depend on the wavy edge. Check the Mermaid version if you care about the stencil. I care about the two paths.

Direction is TD, top to bottom, because this is a decision you read downward. I'd switch to LR only if it were a pipeline with no diamond. A left-to-right decision chart makes the yes and no branches fight for space, and the question gets lost in the middle of a wide picture.

If this text fails in your preview, the usual cause is a smart quote from a chat app, or a label someone edited to include parentheses without quotes. The quoted form is gate{"Over the limit (100)?"}. I keep the number out of the diamond when I can and put it in the prose under the figure. The diamond should stay a question a tired reviewer can read on a laptop screen.

The ids are short on purpose. gate, capture, hold. If the label changes from "Reviewer checks the order" to "Fraud checks the order", the arrows still point at review. That's the whole reason the id and the label are different words. People who are only viewing can ignore this. People who are about to edit should not.

A payment sequence, because order is the point

A flowchart was the wrong picture for the next snippet in that same ticket. The author wanted the shop calling payments, and payments calling the bank. Who speaks, and what comes back, is the content. I paste a sequence instead of forcing that story into boxes.

sequenceDiagram
    autonumber
    participant Shop as Shop
    participant Pay as Pay
    participant Bank as Bank
    Shop->>Pay: Charge the card
    Pay->>Bank: Authorize
    alt approved
        Bank-->>Pay: OK
        Pay-->>Shop: Paid
    else declined
        Bank-->>Pay: No
        Pay-->>Shop: Failed
    end

Participants are declared first, left to right, in the order a reader should meet them. If you let the first message invent the cast, a late name jumps to the right and the story reads backwards. I've seen Bank end up on the left because it was mentioned in a note above the first arrow. Declare the cast. Then talk.

Solid arrows are requests. Dotted arrows are replies. That habit is the difference between a sequence I can review and a pile of lines that all look like new work. autonumber is there so a review comment can say "step 4" instead of quoting the label. Don't also type numbers into the message text. Two numbering schemes means the comment points at the wrong step, and then you "fix" a message that was already right.

The alt needs its end. Delete that closer and the preview fails, often pointing at a later line, which feels unfair. Put the closer back before you touch the messages. I keep the two branches short on purpose. The HTTP path and the error code belong under the figure, or the lifelines get pushed apart by a sentence on an arrow.

If you only wanted to view this and the preview is blank, count the blocks. One alt, one else, one end. A second end with nothing open is also a failure. Extra closers are as bad as missing ones. I check that with my eyes before I ask the tool to be clever.

PNG when the picture has to leave the tab

Viewing is free. Exporting is a separate choice, and it's where plans show up.

PNG works on every plan. On the free plan it's 1x with a small watermark. Starter is $6.99 a month, and that PNG is watermark-free up to 4x. JPG, SVG, and PDF are Pro-only. Pro is $11.99 a month. I mention the prices because people assume every format sits on the free preview. The preview is free. The vector download is not.

I export a PNG when the destination is a ticket field, a slide, or a doc that only accepts an image. I use the PNG converter for that snapshot. I reach for the SVG converter when the picture will be scaled, and only if the plan covers it. If you're on the free plan and someone asks for SVG, send the source and a 1x PNG, and say the vector file needs Pro. Don't redraw the chart in another tool to avoid that sentence. The redraw will drift, and you'll maintain two pictures.

A watermark on a free PNG is small, and it's still the wrong file for a customer-facing packet. I learned that by attaching one to a status deck. Use a plan that drops the watermark before the image leaves the company, or keep the image internal and send the source.

Scale is a pixel multiplier. 4x is a lot of pixels. I don't default to the maximum. I export a modest scale for a slide and look at the file size before I attach it to a thread that will quote the image back forever. Pixels are not free in an email archive, even when the preview was.

The image is not the source of truth. Commit the Mermaid text. If you only commit the PNG, the next edit is a redraw. The diff becomes a binary blob, and nobody can see which label changed. I've been the person who approved that blob. Don't make me do it again.

The official live editor, and when I still open it

The Mermaid project ships its own live editor. I'm not going to invent a feature list for it. If you want a comparison, read the live editor comparison and judge the difference yourself.

I still open the official editor when I suspect my snippet is fine and a viewer is stale, or when I'm checking an example from the official docs and I want their page under the diagram. I don't use it for the repo's day-to-day edits. Those stay next to the text I'll commit.

If a diagram renders in one editor and fails in the other, compare the text first, including characters you can't see. Then compare versions. I'm not going to guess which Mermaid version a hosted editor is running this month. When the text matches and the results don't, say so in the pull request and paste both errors. A shrug of "it works on my tab" is how diagram bugs rot.

I also don't treat either editor as a place to store the diagram. The storage is git. The editor is a viewer with a text box. If that sounds austere, good. Austere is how you avoid a second source of truth.

Mistakes that show up in the first ten minutes

These are from real reviews, including mine.

1. Pasting a whole README, fence included, into a box that expects raw Mermaid. Extract the block, or use the markdown viewer.
2. Treating a failed preview as a reason to switch diagram types. A syntax error is not a hint that you wanted a class diagram. Fix the line.
3. Naming the last node end. Write done([Done]) or stop([Stop]). The word end already means "close the block."
4. Exporting PNG, deleting the text, and calling the ticket done. The next person can't edit pixels.
5. Adding (v2) to a label with no quotes because the service got a version. api["Billing API (v2)"] parses. The unquoted form often doesn't.
6. Rewrapping a sequence into a flowchart because the flowchart tab was already open. If the question is who calls whom, keep the sequence.

One more, because it bites people who are only trying to look. Don't "fix" indentation in a mindmap while viewing. In a mindmap the indent is the structure. In a flowchart it isn't. If you normalize whitespace on the way to a preview, you can change a mindmap and think the original author drew it that way.

Another one from a repo I still maintain: someone viewed a diagram, saw a cramped layout, and inserted <br> tags to wrap labels. Mermaid isn't HTML here. The tags showed up as text, or they broke the line, depending on the build. Wrap by shortening the label. Put the sentence in the paragraph under the figure, where sentences belong.

If the preview itself is what's confusing you, how a render works is the closer read. The format notes cover how the text is structured before you restyle it. If you're deciding whether to start a diagram you haven't written, the notes on a free online diagram are the adjacent question. For text you already have, stay on this page, paste it, and read the error if there is one.

I keep a personal rule for review day. If I can explain the picture without opening the PNG, the text is doing its job. If I need the PNG to remember what we decided, the text is a caption generator and the decision lives in the wrong place. Move the decision into a node label or an arrow label, then view it again. The second viewing should be boring. Boring means it parsed and it says the thing.

Paste the snippet into the editor and read the preview before you install anything. If it fails, fix the line it names, then export a PNG only when something outside the repo needs the picture.