the graph layout series: a survey

2026-05-17#engineering#deep-dive#graph-layout

a graph is just a list of nodes and the edges between them. there are no positions in that list. every picture of a graph you have ever seen was made by an algorithm that decided where each node goes.

and different algorithms decide differently. the same graph can look like a tangle, a set of clusters, or a neat top-to-bottom flow. all three are correct. they just show different things.

that is what this series is about: the main ways to lay out a graph, how each one works, and when to use it.

here is one small graph drawn seven ways. click through them. the data never changes, only the picture:

crossings 0edge length spread 0.28same input, same picture no

force-directed. springs and charges from a random start. run it again: new seed, new picture, same graph.

the same 16 nodes and 19 edges every time. colors mark depth in the tree; only the layout changes.

what "readable" means

people who draw graphs mostly agree on what makes one easy to read:

  • few edges crossing each other
  • edges of similar length
  • nodes that don't overlap
  • some symmetry
  • small changes to the graph cause small changes to the picture

the catch: you can't have all of them at once. pulling connected nodes close makes clusters, and clusters make crossings where they meet. even "fewest crossings" alone is too hard to solve exactly for big graphs.

so every algorithm picks a few of these goals and gives up on the rest. that choice is the most useful thing to know about it.

seven families

each card says what the family is good at and what it gives up. open one for a bit more.

force-directed

part 1 →
optimizes
even edge lengths; clusters appear on their own
gives up
same picture every run; speed on big graphs
reach for it
general networks, like social graphs
read more ↓

nodes push each other away, like magnets. edges pull their two ends together, like springs. let it run until things stop moving. clusters show up on their own, without you telling it anything.

run it twice and you can get two different pictures: the starting positions are random, and there's more than one shape it can settle into. fix the random seed if you need the same picture every time. it also gets slow past about a thousand nodes. parts 1 and 2.

hierarchical (sugiyama)

part 3 →
optimizes
everything flows one way, top to bottom
gives up
clusters; loops get drawn as upward arrows
reach for it
dependencies, pipelines, flowcharts
read more ↓

for graphs with a direction, like "this depends on that". every node goes on a row, and edges point downward. if the graph has loops, a few edges get flipped so everything can point down. it's great when there's a real "up", and it looks wrong when there isn't. part 3.

tree layouts

part 4 →
optimizes
zero crossings, tidy and compact
gives up
only works on trees
reach for it
org charts, file systems, parse trees, taxonomies
read more ↓

a tree has no loops, so it can always be drawn with zero crossings. the idea: draw each child's subtree, pack them side by side as tightly as possible, and center the parent above. the same idea also gives circular (radial) trees, zoomable (hyperbolic) trees, and treemaps, where each node is a box sized by its value. part 4.

spectral

part 5, coming soon
optimizes
speed; close in the graph means close on screen
gives up
looks; ignores crossings and overlaps
reach for it
a quick first draft of a big graph
read more ↓

no simulation at all. build a matrix from the graph, compute two special vectors from it (eigenvectors), and use them directly as x and y. it's fast and always gives the same answer. but it doesn't care about crossings or overlaps, so the result often looks odd. part 5.

constraint-based

part 5, coming soon
optimizes
your own rules, like alignment or no overlap
gives up
speed and simplicity
reach for it
you know how parts of the picture should sit
read more ↓

like force-directed, but you can add rules it must follow: "these nodes line up", "A stays left of B", "nothing overlaps". rules win over the physics. that's great when you know things about your data, and slower than plain force-directed. part 5.

orthogonal

part 6, coming soon
optimizes
right angles, few bends
gives up
organic shapes; slow on big graphs
reach for it
circuits, network maps, UML diagrams
read more ↓

every edge is made of horizontal and vertical lines with right-angle bends, like a circuit diagram. the algorithm tries to use as few bends as possible. perfect for schematics, useless for messy real-world data, and slow on big graphs. part 6.

circular, arc, chord

part 7, coming soon
optimizes
every node visible at once
gives up
local structure, unless the order is good
reach for it
seeing which groups connect to which
read more ↓

put the nodes around a circle (or on a line, for arc diagrams) and draw the edges across. position is just a formula, so it's instant. the only hard part is the order of the nodes: a good order groups related edges, a bad one makes a hairball. part 7.

how to choose

the name of an algorithm tells you how it works. these questions tell you whether it fits:

does it need to look the same every time? force-directed usually doesn't unless you fix its seed. the others do.

how big is it? force-directed needs tricks past a thousand nodes. circular and spectral handle huge graphs easily.

does it change while people look at it? force-directed and constraint-based can update in place. layered layouts usually redraw from scratch, and the picture can jump.

do you need rules, like pinned or aligned nodes? that's what constraint-based is for.

what shape is the data? a tree wants a tree layout. something with a direction wants layered. a general network wants force-directed. a schematic wants orthogonal.

try it here:

my graph is
it has
and I need
  1. 1. force-directed+ discovers clusters with no hints
  2. 2. constraint-based+ energy term still clusters things
  3. 3. circular, arc, chord+ shows density between groups
  4. 4. spectral+ preserves global distances, - rarely pretty on its own
  5. 5. hierarchical (sugiyama)- invents a hierarchy that is not there
  6. 6. orthogonal- useless for organic data
  7. 7. tree layouts- only for trees
a rule of thumb, not an oracle. the scoring mirrors the dimensions in this section; every '+' and '-' is one of them.

the one idea to keep

there is no best layout algorithm. each one has its own idea of what "readable" means. if the picture looks wrong, tweaking settings rarely fixes it. switching to a different family usually does.

the series