Flowcharts That Stay Readable

After reading this you will know what a flowchart can and cannot express, which of the five standard shapes to reach for, how to keep arrows unambiguous, and how to export a diagram that stays sharp in a slide deck.

What a flowchart is, and one quick example

A flowchart is a directed graph drawn with a small, fixed vocabulary of shapes. Each shape means something. Boxes do work, diamonds ask questions, arrows show the order things happen. The whole point is that a reader who has never seen your process can trace it top to bottom without a legend.

Here is the smallest useful example. A login check has three steps: read the password, test whether it matches, and either grant or deny access. That is one input shape, one decision, and two terminators. Three shapes and four arrows describe the entire flow. You could write it as prose, but the diagram makes the two branches visible at a glance instead of hiding them in an "if" sentence.

The convention that gives shapes meaning is old and stable. It traces to ANSI X3.5 (1970) and its successor ISO 5807:1985, which fix the meanings of the process rectangle, the decision diamond, the terminator, and the input/output parallelogram. Because the meanings are standardized, a reader in another team reads your diagram the same way you drew it.

The five shapes and what each one promises

The editor gives you six shape types. Five carry standard meaning; the sixth is a plain text label. Treat the meanings as promises to the reader.

Terminator (rounded pill)

Start or end of the flow. A diagram has exactly one start. It may have several ends, one per outcome.

Process (rectangle)

An action that changes state and always finishes. Exactly one arrow in, exactly one arrow out. "Validate password", "charge card", "write row".

Decision (diamond)

A test with two or more labeled exits. One arrow in, at least two out. Each exit label is a mutually exclusive answer: yes/no, or < 100/≥ 100.

Input/output (parallelogram)

Data crossing the boundary of the system: a form submitted, a report printed, a message read.

Database (cylinder)

Stored state you read from or write to. Not standard in ANSI X3.5, but universal in modern practice for a datastore.

When a flowchart helps, and when it does not

Flowcharts earn their keep when control flow branches and loops. If a process is a straight line of five steps with no decisions, a numbered list is shorter and easier to edit. The break-even point is roughly one decision: with zero decisions prefer text, with one or more decisions the diagram usually wins.

They stop helping past about 25 shapes on one canvas. Reading a flowchart is tracing arrows by eye, and arrow crossings grow faster than shape count. A diagram with 40 boxes and 60 connectors is a maze. When you hit that size, split it: one high-level diagram of 8 to 12 boxes, and separate detail diagrams for the boxes that deserve them.

Flowcharts are also the wrong tool for three things: data structure (use an entity diagram), timing between parties (use a sequence diagram), and quantities over time (use a chart). A flowchart shows order of steps, not shape of data and not magnitude.

Counting complexity: a number you can check

You can measure how tangled a flow is before you even finish drawing it. Cyclomatic complexity, defined by Thomas McCabe in 1976, counts the independent paths through a flow graph. For a connected diagram it is:

Here E is the number of arrows (edges), N is the number of shapes (nodes), and M is the count of independent paths. The intuition: a straight line of N boxes has N - 1 arrows, so M = (N-1) - N + 2 = 1, one path. Every decision that adds a branch adds exactly 1 to M.

Why care? M is also the number of distinct routes a reader (or a test suite) must trace to cover the diagram. A flow with M = 3 needs 3 walkthroughs to exercise every branch. If your one diagram scores above 10, it is doing too much and should be split, the same threshold McCabe proposed for a single function.

How branch count reshapes reading effort

Each decision you add multiplies the routes a reader must hold in mind. Two independent yes/no decisions on the same path produce 2 \times 2 = 4 end-to-end paths; three produce 2^3 = 8. This is why a diagram feels manageable at two decisions and unreadable at six: 2^6 = 64 paths.

Common mistakes that make a diagram wrong, not just ugly

Some errors are cosmetic. These change the meaning:

• Unlabeled decision exits. A diamond with two bare arrows is ambiguous. Every exit needs its condition. If you cannot label an exit, the test in the diamond is not well defined.
• Non-exhaustive exits. If a diamond asks count > 0? it needs both a true and a false exit. A diamond with only a yes arrow strands the no case.
• Overlapping conditions. Exits like ≤ 100 and ≥ 100 both match exactly 100. Use < 100 and ≥ 100 so every input takes exactly one exit.
• Dangling shapes. A box with no arrow out is unreachable in reverse: the reader cannot tell what happens next. Every non-terminator needs an outgoing arrow.
• Crossing arrows you could avoid. Moving a shape often removes a crossing. Because connectors here stay anchored to shapes, you can drag freely and the arrows follow.

Exporting so the diagram survives

Export as SVG when the diagram goes into a document, wiki, or slide that people will resize. SVG is vector: the shapes are described by coordinates, not pixels, so a diagram scales from a thumbnail to a projector without blur. Export as PNG for a fixed pixel target such as a chat message or an issue tracker; the PNG here renders at 2x resolution, so a 400 by 300 diagram becomes an 800 by 600 image that stays crisp on high-density screens.

Export the JSON file when you want to keep editing later or move the diagram to another device. Autosave keeps a copy in your browser's local storage, but that copy is tied to one browser on one machine and clears if you wipe site data. The JSON file is the portable, permanent version.

Related tools

If your flow describes a computation and you want to check the actual numbers a branch produces, sketch it here, then run the logic in the Python Playground to confirm each path returns what the diagram claims.

Related tools

HTML & JS Playground

Write HTML, CSS and JavaScript with a live preview and console.

Python Playground

Run Python with numpy, pandas and matplotlib in your browser.

LaTeX Equation Editor

Type LaTeX, see the rendered formula live; export SVG or PNG.

Base64 / URL / HTML Encoder-Decoder

Encode and decode Base64, hex, URL percent-encoding and HTML entities — with auto-detect, bulk lines and file drop.

CSS Gradient, Shadow & Radius Generator

Visual generators for gradients, box-shadows and border radii.

Color Converter & Contrast Checker

HEX ↔ RGB ↔ HSL ↔ OKLCH, plus WCAG contrast ratios.