State Machine Designer

State Machine Designer

Design finite state machines visually. Define states, transitions, actions. Generate XState code. Free online FSM and statechart editor

A finite state machine is the right abstraction whenever your code says "if status === 'pending' and event === 'paid'..." for the 50th time. State machines make valid transitions explicit, prevent illegal states by construction, and serve as a single source of truth for behavior. This designer is a visual FSM editor — define states, draw transitions, mark final states — and exports as XState code, Mermaid diagrams, or plain JSON.

When to use a state machine

  • Anything with explicit "status" or "phase" field — orders (pending → paid → shipped → delivered), subscriptions (trial → active → past_due → cancelled), authentication flows, UI loading states.
  • Multi-step workflows where order matters — checkout, onboarding, document approval.
  • UI with several modes (idle, loading, success, error) — useEffect chains in React often hide this.
  • Game logic — character states (idle, moving, attacking, dead), AI behavior trees, game-loop modes.
  • Network connection management — disconnected, connecting, connected, reconnecting.
  • Anywhere "this state cannot exist" or "this event cannot happen here" matters — make it impossible by not defining a transition.

Working example: an e-commerce order

Input

States: cart, checkout, payment_pending, paid, shipped, delivered, refunded, cancelled

Output

cart → checkout: on(START_CHECKOUT)
checkout → payment_pending: on(SUBMIT_PAYMENT)
payment_pending → paid: on(PAYMENT_CONFIRMED)
payment_pending → cancelled: on(PAYMENT_FAILED)
paid → shipped: on(SHIP)
shipped → delivered: on(DELIVERED)
shipped → refunded: on(REFUND_REQUEST)
paid → refunded: on(REFUND_REQUEST)
[any] → cancelled: on(CANCEL) [if cancellable]

XState (JavaScript) export:
  const orderMachine = createMachine({
    initial: 'cart',
    states: {
      cart:            { on: { START_CHECKOUT: 'checkout' } },
      checkout:        { on: { SUBMIT_PAYMENT: 'payment_pending' } },
      payment_pending: { on: { PAYMENT_CONFIRMED: 'paid',
                                PAYMENT_FAILED: 'cancelled' } },
      paid:            { on: { SHIP: 'shipped',
                                REFUND_REQUEST: 'refunded' } },
      shipped:         { on: { DELIVERED: 'delivered',
                                REFUND_REQUEST: 'refunded' } },
      delivered:       { type: 'final' },
      refunded:        { type: 'final' },
      cancelled:       { type: 'final' },
    },
  });

Explicit state machines prevent bugs: e.g., a "delivered" order cannot transition to "shipped" — there is no such transition defined. Hard to do that by mistake. Without the state machine, this is a series of "if status === ..." checks that someone forgets to update somewhere.

Features that distinguish good designs

  • Guards / conditions — transitions that only fire when a condition is met. "Can cancel only if payment_pending OR not yet shipped".
  • Actions / side effects — when entering or leaving a state, do something (send notification, update database, log).
  • Hierarchical (statecharts) — nested states. "Authenticated" parent state has child states "loading", "logged_in", "logging_out". Transitions inherited from parent unless overridden.
  • Parallel states — multiple independent state regions running concurrently. Cart's payment state and shipping state are independent.
  • History states — return to where you were. Useful for "back" buttons that should remember sub-state.
  • Internal vs external transitions — internal stays in the same state but re-runs entry actions; external exits and re-enters.

When to reach for this tool

  • You are designing a new feature with several distinct states and want to model behavior before coding.
  • You inherited code with a tangle of "if status === ..." checks and want to refactor toward an explicit state machine.
  • You are documenting business logic for non-developers — diagrams communicate better than code.
  • You are reviewing a complex flow and want to verify all transitions are intentional (no orphan states, no missing transitions).

What this tool will not do

  • It will not implement the state machine in your code. Export to XState / your-language equivalent; the implementation goes in your codebase.
  • It will not verify the design semantically. Whether "cancelled → shipped" should exist is your decision; the tool draws what you specify.
  • It will not handle infinite states. Designed for finite, hand-modeled FSMs — typically under 20 states. For richer state spaces (millions of states), simulation tools like SPIN, TLA+ are appropriate.
  • It will not detect bugs in your implementation. The state machine is correct as drawn; whether your code matches it is a code review / test question.

Frequently asked questions

What is the difference between FSM and state chart?

FSM (finite state machine) — flat list of states, transitions between them. State chart (statechart, Harel statechart) — adds hierarchy (states within states), parallelism (multiple state regions running concurrently), history. Statecharts handle complex UI well; flat FSMs are sufficient for simple workflows.

When should I NOT use a state machine?

For data flow without sequential constraints — a record's fields can be edited in any order, no "phases". For pure computation (transform A to B). For "everything is just status flags" — sometimes a state machine adds bureaucracy without value.

Should I use XState in production?

For complex multi-step flows: yes. XState handles statecharts (hierarchy, parallelism, guards, actions) with strong TypeScript support. For very simple "two-state" flows, a plain useState often suffices. XState pays off when the state machine has 5+ states and 10+ transitions.

How is a state machine different from a workflow?

Overlap, but workflows are often longer-running, persistent, and may include human tasks (approvals). State machines are usually shorter-lived, all-machine. Workflow engines (Temporal, Camunda, AWS Step Functions) are state machines with persistence and visibility added.

Can my state machine have cycles?

Yes — many do. "Subscription past_due → active" (after payment) → eventually "past_due" again. Cycles are normal. The "final state" concept marks states from which no transitions exit (delivered, cancelled, completed).

How big should a state machine be?

Rule of thumb: if a state machine has more than ~10 states, consider hierarchy or splitting into multiple machines. Flat 50-state FSMs are unreadable. Hierarchical statecharts handle complexity better.

Related tools

Database Schema Designer

Visual ERD designer for database schemas. Create tables, define relationships, foreign keys. Export to SQL for MySQL, PostgreSQL, SQLite. Free online ERD tool

Architecture Diagrammer

Create C4 model architecture diagrams. Design system context, container, component diagrams visually. Export to PNG/SVG. Free software architecture tool

Diagram & Flowchart Editor

Create flowcharts, UML diagrams, mind maps visually. Export to SVG/PNG. Free online diagram maker and flowchart creator

JSON Tree Diff

Compare two JSON documents with visual tree diff. Highlight added, removed, modified nodes. Expandable tree view. Free online JSON comparison tool

Last updated · E-Utils editorial team