Type a number, press Add, and the value drops into a binary search tree at the one position the ordering rule allows. Run five traversal orders against the same tree and compare the output lists side by side.
Whole numbers only. Duplicates are refused.
A hit flashes amber on the canvas for 1.5 seconds.
Add a value or press Random tree to start.
One node lights up per step. All five visit every node, and only the order changes.
No traversal run yet.
The values you store matter far less than the sequence you store them in.
Feed the numbers in ascending order and every new value loses the comparison at every node, so it walks right, right, right, and lands at the bottom of a single chain. The diagram still calls itself a tree. It behaves like a list. Try it: clear the canvas, then add 10, 20, 30, 40, 50 one after another and watch the drawing lean off to one side.
10 \ 20 \ 30 \ 40 \ 50
Height 5, leaves 1. Searching for 50 touches all five nodes.
30 / \ 10 40 \ \ 20 50
Height 3, leaves 2. The same five values, two fewer levels.
Rebalance reads the tree out in sorted order, takes the middle value as the new root, then repeats on each half. Standard sorted-array-to-BST rebuild, height around log₂(n). It fires once when clicked and then stops caring. Five more ascending inserts and the shape sags again. Self-balancing structures such as AVL and red-black trees rotate on every insert to prevent exactly this, and none of those rotations are modelled here.
Building a demo for a lecture in ten minutes? Insert 10, 20, 30, 40, 50, screenshot the lean, press Rebalance, screenshot again. Two images, one argument, no slides needed.
Read this part before you rely on the tool for coursework.
parseInt, so 3.7 is stored as 3 and text is refused with an Enter a number toast. Negatives work fine.Weighted edges, shortest paths, or cycles? A tree is the wrong model. The graph theory calculator handles those.
Add 50, 30, 70, 20, 40, 60, 80 in that sequence for a tree three levels deep with four leaves. Every button in the console visits all seven nodes.
| Order | Visit rule | Result |
|---|---|---|
| Inorder | left subtree, node, right subtree | 20 30 40 50 60 70 80 |
| Preorder | node, left subtree, right subtree | 50 30 20 40 70 60 80 |
| Postorder | left subtree, right subtree, node | 20 40 30 60 80 70 50 |
| Level order | row by row from the root down | 50 30 70 20 40 60 80 |
| Reverse level | bottom row first, left to right within each row | 20 40 60 80 30 70 50 |
Memorise the inorder row. On a binary search tree it comes back sorted every time, which makes it the fastest check on whether the ordering rule survived every insert. Preorder hands you a serialisation you replay to rebuild the identical shape. Postorder is the order a recursive delete uses, since children are freed before their parent.
A fifteen-node tree at the default 800ms step takes twelve seconds to finish. Drag the step slider down to 100ms before running anything on a random tree.
The four tiles in the rail recompute on every insert with recursive walks over the whole tree, not running totals, so a rebalance leaves them correct.
5 four times leaves the count at 1 and the toast reads Value already in tree.Quote a height from this page in an assignment and you are quoting the node-counting convention. Confirm which one your course uses first.
A binary search tree. Inserts follow the ordering rule, so smaller values go left and larger values go right. You cannot place an arbitrary value at an arbitrary position, which is what a general binary tree editor would allow.
The insert routine compares against each node on the way down and returns false on an exact match, so duplicates are dropped and the node count stays put. Production BSTs usually handle repeats with a count field on the node or by sending equal values consistently to one side.
Both, under different definitions. This tool counts nodes on the longest root-to-leaf path. Many textbooks count edges instead, which is always one less. Check which convention your course uses before quoting a figure from here.
Run the Inorder traversal. On a binary search tree it visits values in ascending order every time, so the output row doubles as a sort check. If it comes back out of order, something is wrong with the tree rather than the traversal.
No. It is a one-shot rebuild from the sorted values. Add several increasing numbers afterwards and the height climbs again. Press Rebalance a second time to flatten it back down.
It visits the deepest row first and works up to the root, which suits bottom-up work such as computing subtree sums or freeing memory level by level. It is also a common interview follow-up once you have written the standard level order queue.
