Flowchart Symbols and Their Meanings Explained

If you've ever tried to map out a process on paper or in a tool and wondered what all those shapes mean, you're not alone. Flowchart symbols are the visual language of process diagrams and understanding them is the difference between a chart that confuses people and one that makes a process crystal clear. Whether you're documenting a workflow, planning software logic, or explaining a business process to your team, knowing the right symbol for each step keeps everyone on the same page.

What are flowchart symbols, and why do they have specific meanings?

Flowchart symbols are standardized shapes used in flowchart diagrams to represent different types of actions, decisions, inputs, and outputs. Each shape carries a specific meaning so that anyone familiar with flowchart conventions can read the diagram without extra explanation.

This standardization comes from organizations like the International Organization for Standardization (ISO) and ANSI, which defined many of the symbols decades ago. The result is a shared visual grammar that works across industries from software development to manufacturing to healthcare.

When you use the right symbols, your flowchart communicates faster. When you use them wrong or inconsistently, people spend more time guessing what you meant than actually understanding your process.

What are the basic flowchart symbols everyone should know?

Most flowcharts use a small set of core symbols. These cover about 90% of what you'll need:

Oval (Terminator)

The oval or rounded rectangle marks the start and end points of a flowchart. Think of it as the entry and exit doors of your process. Every flowchart needs at least one start oval and one end oval.

Rectangle (Process)

The rectangle is the most common shape you'll use. It represents any action, task, or operation in the process. Examples: "Send email notification," "Calculate total," "Update database record."

Diamond (Decision)

The diamond represents a yes/no question or decision point. It always has two or more exit paths. Common examples: "Is the order valid?" → Yes leads one way, No leads another. This is the shape that creates branching logic in your diagram.

Parallelogram (Input/Output)

The parallelogram represents data entering or leaving the process things like user input, file reads, display output, or printed reports. It signals that information is crossing the boundary between the system and the outside world.

Arrow (Flowline)

Arrows or flowlines connect the other symbols and show the direction of flow. They tell the reader which step comes next. Without arrows, a flowchart is just a collection of disconnected shapes.

What about the less common flowchart symbols?

Beyond the basics, several specialized symbols show up in more detailed or technical diagrams:

Document symbol (rectangle with a wavy bottom edge) represents a physical or digital document, like an invoice or report
Database symbol (cylinder) represents data storage, like a database or file system
Predefined process (rectangle with double vertical lines) a process defined elsewhere, like a subroutine or referenced workflow
Connector symbol (small circle) used to jump between different parts of a flowchart without drawing long arrows across the page
Manual operation (trapezoid) a step that requires human manual work, not automated
Delay symbol (half-oval or D-shape) represents a waiting period in the process
Display symbol (rounded shape with flat bottom) output shown on a screen
Merge symbol (inverted triangle) where multiple flow paths combine into one

You won't need all of these for simple diagrams. But when you're mapping complex workflows or technical processes, these shapes help you be more precise.

When should I use a flowchart instead of just writing steps out?

A written list works fine for simple, linear sequences. A flowchart becomes valuable when your process has:

Decision points branches where different things happen depending on a condition
Multiple paths more than one way to move through the process
Parallel tasks steps that happen at the same time
Loops steps that repeat until a condition is met
Multiple stakeholders people who need to understand their role at each stage

For example, a customer support process might branch based on issue type, escalate through different tiers, and loop back for follow-up. That's hard to explain in paragraphs but easy to read in a flowchart.

What are common mistakes people make with flowchart symbols?

Here are the errors that show up most often and how to avoid them:

Using rectangles for everything. When every shape is a box, readers can't tell where decisions happen or where data flows in and out. Use the correct shape for each step type.
Forgetting start and end points. A flowchart without terminators leaves the reader wondering where the process begins and ends.
No arrows or inconsistent flow direction. Typically, flowcharts read top-to-bottom or left-to-right. Mixing directions without clear arrows creates confusion.
Making decision diamonds too vague. "Is it okay?" doesn't help. Be specific: "Is payment verified?" with clear Yes/No labels on each exit path.
Overcomplicating the chart. Not every sub-task needs its own box. Group low-level details into a predefined process symbol and describe them separately if needed.
Ignoring standard symbol meanings. If you use a diamond to mean something other than a decision, readers who know the conventions will misread your chart.

How do flowchart symbols compare across different notation styles?

The standard ANSI/ISO symbols described above are the most widely recognized. But if you work in software or systems engineering, you might encounter UML (Unified Modeling Language) activity diagrams, which use a slightly different set of shapes for similar concepts.

For instance, UML uses rounded rectangles for activities (similar to process rectangles), a filled circle for start, and a bullseye for end. The decision node is a diamond, which is consistent with standard flowcharts. If you need to understand the differences between these notations, our comparison of UML and standard flowchart notation breaks it down step by step.

Can I use these symbols in code or text-based tools?

Yes. Tools like Mermaid let you define flowcharts using simple text syntax, which renders into visual diagrams. You write shapes and connections with short code lines, and the tool handles the layout and symbols for you.

For example, a Mermaid flowchart uses keywords like flowchart, st for start, end for end, and {} for decision nodes. If you want to see real working examples, check out our Mermaid flowchart code examples. And if you need a quick reference for all the syntax options, the flowchart syntax reference guide covers everything in one place.

What's the best way to start building my first flowchart?

Here's a practical approach:

Write out the process steps first list them in order before you open any tool
Identify decision points circle any step where the outcome determines the next step
Assign symbols match each step to the correct shape (process, decision, input/output, etc.)
Draw the flow connect shapes with arrows, reading top-to-bottom
Label decision paths mark every exit from a diamond with Yes/No or a specific condition
Review with someone else have a colleague trace the flow to check for gaps or confusion

Quick reference: flowchart symbols at a glance

Oval Start / End
Rectangle Process / Action step
Diamond Decision (Yes/No question)
Parallelogram Input or Output
Arrow Flow direction
Document shape A document or report
Cylinder Database or storage
Circle Connector (jump point)
Double-bordered rectangle Predefined / referenced process

Try this next

Pick one real process you deal with regularly onboarding a new hire, handling a refund request, deploying code and map it out using the correct symbols. Start with the basic five shapes. If your process has more than 15 steps, break it into sub-flowcharts connected by predefined process symbols. This single exercise will teach you more about flowchart symbols than any reference list alone.