Putting a Mermaid error on the line you typed, when Mermaid counts lines differently
A Mermaid parse error names a line, and in a diagram of any size that line is usually wrong. Before it parses anything, Mermaid removes the front-matter block between the --- lines, every line that is only a %% comment or an %%{init}%% directive, and any blank lines ahead of the diagram, and then numbers what is left. So a diagram with a four line title block and two comments that is broken on line 11 of the editor is reported as broken on line 5. An editor that marks line 5 marks the wrong line, and one that shows the raw message sends you counting. This page rebuilds Mermaid’s numbering instead: core/diagram/errors walks the text, skips exactly what Mermaid skips, and keeps a list of which editor line each surviving line came from, so Mermaid’s line n is simply the nth entry. Blank lines inside the diagram are kept, because Mermaid keeps those. The rule was measured against Mermaid 12.0.0 rather than read from its documentation, and the unit tests run the real parser on broken diagrams with directives, front matter, comments, blank lines and Windows line endings, then check the mark lands on the line that holds the mistake. An upgrade that changes the numbering fails those tests instead of quietly moving the underline.
Mermaid’s parsers do not agree on how they report a position either. The older grammars, which cover flowcharts, sequence, class, state and entity relationship diagrams, mind maps and Gantt charts, attach a location object to the error whose first line is where the offending token starts. Their message names a different line, the one where the parser gave up, which for an unclosed bracket is the line after the bracket. Using the message would put the underline one line late in exactly the most common mistake. The newer grammars used by pie, packet, architecture and the other recent diagram types carry no location object and write "line 3, column 10" into the message text, so both forms are read. A misspelled diagram type is a third case with no line at all, so the page points at the first line Mermaid reads and compares the word against the two dozen diagram keywords by edit distance. "flowchrt" and "sequencediagram" get a one-click fix; "hello" is not close enough to anything, and gets no guess.
The preview never goes blank while you type. Most of the time a diagram is invalid, because "A --> B" is invalid at "A -" and at "A --". A failed render keeps the last diagram that worked on screen, dimmed and labelled, while the underline moves with your typing, so the picture you are editing stays in view. Renders wait 250 milliseconds after the last keystroke and each one carries a sequence number, so a slow render of an older version that finishes late is thrown away instead of replacing a newer one. Mermaid does run on the main thread, which is the exception to how the rest of this site works: it measures text with getBBox in a live document to size every box, and a worker has no document. The view is fitted once when a diagram arrives, from a file, an example, a link or the first render, and then left alone, so typing into a large flowchart does not keep throwing the zoom back out.
Sharing is where Mermaid editors usually stop being private. The common approach stores the diagram on the editor’s server and hands back a short id. Here the diagram is compressed with the browser’s own CompressionStream in raw deflate and written into the link after the #, in base64url so chat apps do not mangle it. Browsers never send the part of a URL after the # to the server, so the link opens the diagram on anyone’s device and the site never receives it. Opening a link also cannot overwrite your work: the shared diagram is applied to the editor as an ordinary edit, so Undo brings back the draft that was there. Because a link is a diagram somebody else wrote, Mermaid runs in strict mode, which passes the finished SVG through DOMPurify and removes click handlers. A diagram cannot switch that off from inside itself, because securityLevel is on Mermaid’s list of settings an %%{init}%% directive is not allowed to change.
Export is asked as a question about where the picture is going. A PNG for a document is twice the drawn size, crisp on a high-density screen at the width a document shows it. For slides it is as large as fits 3840 by 2160, and for print as large as fits A4 at 300 dots per inch, turned to whichever orientation suits the diagram. The vector is rasterised at that size, rather than drawn small and stretched, and every size is held under 16,777,216 pixels, because that is the largest canvas Safari will allocate and past it Safari returns nothing at all instead of an error. Labels are drawn as SVG text rather than as HTML inside the SVG. HTML labels live in a foreignObject element, which Safari will not draw onto a canvas, so a PNG export that works in Chromium would fail on an iPhone. The same setting is added to Mermaid’s protected list, so a directive in a pasted diagram cannot turn HTML labels back on and break the export. The saved SVG is rewritten from Mermaid’s HTML serialisation into standalone XML at its drawn size, with the theme’s background painted in, so a dark diagram does not open as light text on nothing.