Trie Autocomplete Visualizer — Free HTML CSS JS Snippet

Most explanations of a trie show you a finished diagram and ask you to trust that it makes autocomplete fast. This snippet builds the diagram from a real word list, lays it out as a node graph, and then animates the exact node-by-node descent that happens every time you type a character into a search box backed by a trie — so the claim "lookup time depends on prefix length, not dictionary size" becomes something you can watch happen rather than something you have to take on faith.

Building the trie: a nested object, not a library

The word list WORDS (18 overlapping words like cat, car, care, card, careful, dog, dot, do, done) is inserted one character at a time into a plain nested-object structure. makeNode(char) creates { id, char, children: {}, isEnd, word }, and insertion walks the existing tree, creating a new child node only when the current character has not been seen at that position before. This is the entire trie data structure — no class hierarchy, no external library, just objects referencing objects. Shared prefixes like "car" and "care" and "careful" literally share the same three nodes in memory; the tree only branches at the point the words actually diverge, which is the structural property that makes the whole algorithm work.

Layout: leaf-counting, the same technique real tree-drawing libraries use

layout(node, depth) assigns each node a y equal to its depth and computes x recursively: a leaf node claims the next integer from a shared leafCounter, and every internal node's x is the average of its children's x values. This is a standard "assign leaves left to right, average parents upward" tree-layout algorithm — it guarantees siblings never overlap regardless of how unbalanced the tree is, without needing a charting library. The computed x values are then mapped to a percentage width with pctX, and y to a fixed pixel row height with pxY, exactly the same node-and-edge rendering approach as this library's recursion-tree-visualizer and linked-list-visualizer: absolutely-positioned div.node elements over an SVG layer of <line> edges.

The walk: recomputed from scratch on every keystroke, not incrementally patched

walk() runs on the input's input event, so it fires once per keystroke, backspace, or paste. Rather than trying to incrementally track "what changed since last time," it simply re-walks from the root using the full current input string: for each character, if node.children[ch] exists, descend and push that node onto a path array; the moment a character has no matching child, the loop stops and records deadAt, the index where the walk failed. Recomputing from scratch every time is deliberately simple — the trie is small enough that walking it top to bottom on every keystroke costs nothing measurable, and it completely avoids a class of bugs where a stale highlight from a previous, since-abandoned prefix stays lit after a backspace.

Why this is faster than filtering the whole word list

A naive autocomplete does words.filter(w => w.startsWith(prefix)), which touches every single word in the list on every keystroke — with 18 words that is invisible, but with 200,000 dictionary words it means scanning 200,000 strings per character typed. The trie walk in this snippet touches exactly prefix.length nodes, full stop, regardless of whether the dictionary behind it has 18 words or 18 million: each step is a single object-property lookup (node.children[ch]), and the total work to validate a prefix is bounded by how many characters were typed, never by how many words exist. The Nodes Visited counter makes this concrete — type "care" and it reads 4, never more, no matter how large WORDS becomes.

Suggestions: DFS from the current node, not a fresh scan

Once the walk lands on a live node, collectWords(node, limit) performs a depth-first search rooted at that exact node — not the tree root — collecting the word string stored on every isEnd node it encounters, in sorted child-key order, up to a limit of 8. Because the DFS starts already positioned at the end of the typed prefix, it only ever visits the sub-tree of words that could possibly match; it is structurally incapable of returning a word that does not start with the typed prefix, so no separate startsWith filter is needed anywhere in the suggestion logic.

Dead-end handling as a first-class visual state

When a character has no matching child, the loop breaks immediately rather than continuing to search elsewhere in the tree, and the last successfully matched node gets the .dead-end class — a red fill plus a short CSS shake keyframe — while the message panel explains exactly which prefix substring was still valid. This mirrors what a real trie-backed autocomplete does in production: it does not fall back to fuzzy matching, it reports "nothing here" precisely at the character where the tree structurally has nothing to offer, and this snippet makes that failure mode as visible as the success path.