A free sequence diagram maker that stays in text

A free sequence diagram maker, the kind I will actually use twice, is a text box with a preview. You name the participants, you draw a solid arrow for a request and a dotted arrow for a reply, and you stop. No signup, no seat count, no export tax on the first PNG you need for a ticket. The picture is a login, or a charge, or whatever call order you were about to explain in a paragraph. The file stays small enough to live next to the code.

What free means here

Free means the editor opens and renders a sequence diagram without an account. You can paste a fence, fix a missing colon, and copy the text back into a README. That loop is the whole product for a lot of days. I don't want a trial that locks the arrows until I invite a teammate.

The limits are specific, so I won't wave at "free forever" and hope you don't notice. PNG export exists on the free plan at 1× with a small watermark. Starter is $6.99 a month and includes watermark-free PNG up to 4×. JPG, SVG, and PDF are Pro-only, and Pro is $11.99 a month. AI generate, edit, and fix are included as five complimentary uses in total, not five a day. After that, hand editing is still free. I would rather you know the five-use cap before you burn them regenerating a login diagram that needed one arrow flipped.

There is no collaboration claim hiding in that price. A share link is a URL to a diagram, useful in a review comment. It is not a shared cursor, and I don't want one for this. Sequence diagrams in a repo are text. Two people editing them at once is a merge, which git already knows how to do if the file is small. If your diagram is so large that a merge is hopeless, the diagram was too large before the tool choice mattered.

The syntax head term stays on the sequence diagram page. That page owns the arrow table. This post is the free maker: what you type first, what you can ignore, and a login that fits on one screen. If you want a longer course after the login works, the sequence tutorial is the next stop. I am not going to duplicate it under a "free" headline.

Participants before the first message

The order of the lifelines is the order of the participant lines. Left to right is the order a reader meets the cast. I declare every participant before the first arrow, even when Mermaid would invent them from the messages. Invention puts a late name on the right edge. In a login, that often means the database shows up to the right of the user, or worse, the user ends up in the middle because you mentioned the app first. Declare the human on the left, the system in the middle, the checker on the right. Then write messages.

Aliases help when the id is ugly and the label should be plain. participant Auth as Auth service is the form. I rarely need it for a login. Browser, App, and Auth are already words. I use an alias when the code name is svc_auth_v2 and I refuse to put that on a design diagram. The id can stay stable for the arrows. The label can be what you would say in a meeting.

Don't add a participant you never message. A lifeline with no arrows is a person who was in the room and didn't speak. It widens the picture and implies a dependency. If the logging pipeline matters, give it a message or leave it out. Sequence diagrams are bad at "also exists." They are good at "then this happens."

autonumber stamps the messages. I turn it on when a pull request will refer to step 4. I leave it off when the diagram is four messages and the labels are enough. Numbers and labels that repeat the same count, "1. Login" on message 1, are noise. Pick one.

Solid request, dotted reply

Browser->>App: Submit password is a request. The arrow is solid. App-->>Browser: Show home is a reply. The arrow is dotted. That single convention is the difference between a sequence diagram and a pile of arrows. I follow it even when the reply is an error. An error is still a reply. It is not a new request from the server, unless the server really does call you back later on another channel.

The colon is not optional. Browser->>App Submit password is a parse error, or a message that swallows the rest of the line in a way you won't like. The form is participant, arrow, participant, colon, text. I say it while I type until my fingers remember. The example of a sequence diagram post uses the same split if you want a second domain after this login. The rule doesn't change when the nouns change.

Keep the message text to a few words. "Submit password" is enough. The field list, the HTTP path, and the error code belong under the figure or in the handler. A message that is a sentence pushes the lifelines apart until the "sequence" is a very wide paragraph with trunks. If you need the path in the review, put it in the prose: "Submit password hits POST /session." The arrow stays short. The sentence can be precise.

Return arrows are the ones people drop. They draw the request into Auth and then start a new request from Auth to the database without ever answering the user. Sometimes that is the story, a chain of calls with the replies omitted for space. Say so. Otherwise the reader thinks the user is still waiting, and they are right to think that, because you didn't draw the reply. I would rather have a taller diagram than a diagram that forgets to come back.

A login that fits on one screen

Three participants. Two requests. Two replies. The user submits an email and a password. The app asks Auth to check them. Auth answers with a session. The app shows home. If your real login has a sixth hop through a risk engine, this diagram is the lie you tell to start the review, and you should add the hop before you merge the doc. For a first picture, four messages are enough to see whether the maker and the syntax agree.

sequenceDiagram
    participant Browser
    participant App
    participant Auth
    Browser->>App: Submit email and password
    App->>Auth: Check credentials
    Auth-->>App: Session
    App-->>Browser: Home

Read it as time, top to bottom. Nothing in the picture is simultaneous. If Auth and a profile service are both called and the order doesn't matter, this diagram is the wrong tool for that claim, or you should pick an order and label it as the order you chose. Sequence diagrams make unordered work look ordered. That is their bias. Use it on purpose.

The session message is dotted because it is the answer to "Check credentials," not a new job Auth thought up. "Home" is dotted because it is the answer to the submit. I don't label either reply "response." The noun is the point. A session is a different outcome from a rejection, which is why the next diagram exists.

This is also small enough to type by hand, which is the free path I want. The AI sequence generator will draft a login if the cast is fuzzy. Spend a complimentary use on a messy real flow, not on four lines you can type. Hand edits after that draft are free. Flip a solid arrow to dotted. Rename Auth. Don't regenerate to change one word.

When the password is wrong

The happy path is not the diagram your on-call will need. The second picture is the same login with a branch. alt opens the fork. else is the other answer. end closes it. That end is a keyword, not a participant. Don't also create a participant named end. I have done that, and the block closes in the wrong place, and the preview looks like the file was cut off.

sequenceDiagram
    participant Browser
    participant App
    participant Auth
    Browser->>App: Submit email and password
    App->>Auth: Check credentials
    alt password matches
        Auth-->>App: Session
        App-->>Browser: Home
    else password does not match
        Auth-->>App: Reject
        App-->>Browser: Try again
    end

The branch title is the condition, not a second copy of the message. "password matches" is enough. Inside the branch, both arrows are replies. The rejection is not a request from Auth to the app. Auth is answering. The app then answers the browser. Two replies, two different outcomes. If you draw Auth->>App: Reject with a solid arrow, you have said Auth started something. That might be true for a webhook. It is not true for a password check.

I don't put the loop of "user tries again" inside this alt. The back-edge in a sequence is a loop block, and it has its own rules. The loop writeup is where that block gets a full example. The alt writeup is the longer treatment of branches, including a third outcome. This login only needs two. A third else for "account locked" is justified the day the product has that state. Until then it is a fictional lifeline, and fictional lifelines become support scripts.

An OAuth login is a different cast: the browser, your app, and someone else's authorization server, with a redirect that is easy to draw backwards. When that is the real flow, start from the OAuth sequence template and delete messages until it matches your grant type. Don't stretch this password diagram into OAuth by renaming Auth. The redirect is a different arrow pattern, and pretending it is a password post will confuse the one review where the distinction matters.

What I leave out on purpose

Activation bars, notes, and colored boxes are available and usually a mistake on a free-tool diagram you will edit in a hurry. An activation bar says the participant is busy between two messages. It is useful when a long stretch of work is the point. On a four-message login it duplicates the arrows. I leave activate and deactivate out until a reviewer asks where the time goes.

Notes beside a lifeline are how error codes sneak back onto the picture after I removed them from the message text. One note for a real invariant is fine. A note on every message means you wanted a paragraph. Write the paragraph.

I also leave out the database unless the review is about the query. "Auth checks credentials" might hit a table. Drawing the table is a second diagram, or a later edit, when someone asks what is stored. Sequence diagrams grow participants easily and shrink badly. Adding Database on the right forces every reply to cross more whitespace. Add it when the SQL is the bug. Not before.

The sequence diagram software roundup is the wider comparison of text makers and GUI tools. I don't need that comparison to draw a login. I need it when someone asks why we don't license a drawing product for this one picture. The short answer is that the picture is twelve lines and the license doesn't make the colon optional. The long answer is that post.

Keeping it free after the AI uses are gone

The five complimentary AI uses will go to a diagram you were going to draw badly by hand, a gnarly checkout with a timeout. The login in this post should not be one of them. Type it. Preview it. Copy it. That is the free maker doing the job it is good at.

When a use is spent, spend it on a structural fix: "add an alt for the reject path, keep Browser, App, and Auth, dotted replies only inside the alt." Then stop. Changing "Home" to "Dashboard" is a keystroke. Regenerating for a synonym is how you hit the cap and still don't have the reject path. The editor will preview the keystroke for free.

Export follows the same taste. A watermarked 1× PNG is enough for a ticket if the words are readable. I don't upgrade for a login diagram. I upgrade, or I use a local render, when the file has to be an SVG in a docs site or a PDF in a packet someone will print. Those formats are Pro here. If you don't need them, don't pay for them to feel serious. The source in git is the serious part.

Share links are for the person who will not open the pull request. Paste the link, and also paste the fence in the PR. The link can change. The commit should not depend on it. I treat a share link as a convenience, the way I treat a screenshot: helpful, not canonical.

If the preview shows a parse error, look at the line it names before you look at the price page. A missing end, a missing colon, or an else that isn't inside an alt are the three I hit. None of them are fixed by a plan. They are fixed by reading the line.

Open the editor and paste the happy-path login. Then add the alt from the second diagram only after the four straight messages render. If you add the branch first, you won't know whether a failure is the branch or a typo in the participants. Build the straight line. Then fork it.