b2KIT

Binary Tree Visualizer

Insert, delete, and search in BST, AVL, and red-black trees with animated rotations and traversal order highlighting.

Tested tool guide Tested browser tools Checked August 15, 2026

What Binary Tree Visualizer does, with a checked example

This tool builds a binary search tree on screen as you insert, delete, or search for keys, then plays back each rotation or recoloring step so you watch the tree rebalance rather than just see the end state. Switch between plain BST, AVL, and red-black modes to compare how each structure handles the same sequence of keys. The most common surprise: two trees holding the identical set of keys can look completely different in shape, because BST and AVL results depend on the order keys were inserted, not just which keys are present.

Worked example

A concrete input and expected output from the current implementation.

Input

AVL mode, insert in order: 10, 20, 30

Expected output

Root 20, with 10 as its left child and 30 as its right child; balance factor 0 at every node.

Inserting 20 then 30 makes node 10 right-heavy by two levels (a right-right case), so the tool performs a single left rotation at 10, promoting 20 to root with 10 and 30 as its children.

How the result is produced

1

Mode-specific balancing rules

In BST mode each insert walks down comparing keys and attaches a new leaf with no rebalancing, so the tree can degrade into a chain under sorted input. AVL mode tracks a balance factor (left height minus right height) at every node and fires a single or double rotation the moment any node's factor leaves the range -1 to 1. Red-black mode tracks node color and applies the standard recoloring or rotation fixup when a red-red conflict appears.

2

Traversal highlighting

Selecting inorder, preorder, or postorder steps through the current tree and highlights each node in visiting order, so you can check that an inorder walk of a BST or AVL tree yields keys in sorted order. The traversal step order depends only on the tree's current shape, not on its rebalancing mode, so an inorder walk highlights keys in sorted order the same way in BST, AVL, or red-black mode.

Good uses

  • Confirming by hand why a specific AVL insertion sequence forces a left-right double rotation instead of a single rotation
  • Checking that an inorder traversal of a BST you built matches the sorted key order before a data structures exam
  • Comparing the shape of a red-black tree against an AVL tree built from the same key list to see the balance trade-off

Limits and checks

  • Deleting a node with two children requires splicing in either the inorder predecessor or successor; the tool's choice fixes the resulting shape, which can differ from a by-hand answer that picked the other one
  • Red-black insertion fixup has multiple textbook case-orderings (uncle color, then rotation direction); if the animated steps don't match your course notes, check which convention (commonly CLRS) they follow before assuming an error
  • In AVL or red-black mode, large key sets make the tree wide rather than tall since height stays logarithmic, but a wide tree with many nodes can still be hard to fit on a single screen; in BST mode, tall skewed shapes are possible instead depending on insertion order

Common questions

What's actually different between the BST, AVL, and red-black results for the same keys?

BST mode never rebalances, so shape depends purely on insertion order and can become a skewed chain. AVL mode enforces a strict balance factor of -1, 0, or 1 at every node, a tighter constraint than red-black balancing. Red-black mode allows more skew than AVL but still guarantees logarithmic height, usually with fewer rotations than AVL for the same key sequence.

Why did inserting the same numbers in a different order produce a different-looking AVL tree?

AVL rotations depend on the sequence of inserts, not just the final key set. Each insert can trigger a rotation at the first unbalanced ancestor it reaches, so two different insertion orders of the same keys can settle into different but equally valid balanced shapes.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools