Linked List Visualizer — Free HTML CSS JS Snippet

Most linked-list diagrams are static images because animating a real linked list is genuinely fiddly: nodes need to visually connect to whichever node comes next, and that "next" relationship changes shape on every insert and delete. This snippet renders a singly linked list as connected node boxes with CSS arrows between them, and provides insert-at-head, insert-at-tail, insert-at-index, delete-by-value, and a step-by-step traversal that highlights the walk from node to node exactly the way .next pointer-following works in a real implementation.

Data model: an array standing in for pointer-linked nodes

Under the hood, list is a plain JavaScript array of {id, value} objects — deliberately not a class-based Node with a literal .next reference, because array order already encodes the same sequential relationship a linked list's pointers encode, and it makes rendering dramatically simpler. Each node also gets a stable, monotonically increasing id from genId() so the DOM element for a given logical node can be tracked across re-renders even as its position in the array shifts. This id is the detail that makes the removal animation possible: without a stable identity, there would be no way to say "fade out *this specific* node" as opposed to "redraw everything and one fewer box happens to appear."

Why this is fundamentally different from re-rendering the whole list

The naive way to "animate" a list change is to clear the container and rebuild every node from scratch on every operation — which is what most simple to-do-list or table UIs do, and it works fine when nothing needs to visually connect to anything else. A linked list is different: the meaningful visual event isn't "a box appeared," it's "the arrow that used to point from node 2 to node 3 now points from node 2 to node 4, because node 3 was removed." This snippet's deleteValue() function demonstrates the distinction directly: before touching the underlying array, it finds the specific .node-wrap DOM element matching the node being removed, adds a .removing class that triggers a CSS opacity/scale transition, *waits* for that transition via await wait(220), and only then splices the array and calls render(). The old arrow fades with its node; the new, shorter arrow chain fades back in during the next render's entrance animation. That sequencing — animate out, then mutate state, then animate in — is the "animated pointer-rewiring" this component is built around, and it's the same principle you'd apply with FLIP animations or React's AnimatePresence in a framework context.

Insert-at-head is O(1); an array's unshift() is O(n)

Clicking Insert Head calls list.unshift({id, value}). In a *real* linked list backed by actual node objects with .next pointers, prepending a node is O(1): you allocate one new node, point its .next at the current head, and repoint the list's head reference at the new node — no other node is touched or moved. This snippet's underlying representation is a JS array for rendering convenience, and Array.prototype.unshift is actually O(n) internally (every existing element's index shifts up by one) — worth calling out explicitly as the one place this visualization's implementation convenience diverges from true linked-list performance. The about text and this snippet's insert-head status message intentionally teach the *real* linked-list complexity characteristic (O(1) head insertion because only one pointer changes) even though the underlying render array pays a different, JS-engine-specific cost; if you were building a production linked-list data structure rather than a teaching visualization, you'd use actual {value, next} node objects to get the true O(1) behavior.

Insert-at-index and the pointer-rewiring narrative

insertAt() clamps the requested index into range and calls list.splice(idx, 0, node). Conceptually, in pointer terms, this is: walk from the head idx steps to find the node right before the insertion point, create the new node with its .next set to what used to be "the node after," then repoint the previous node's .next at the new node. Only two pointers change no matter how long the list is — everything after the insertion point keeps pointing at whatever it already pointed at. The status message after every insert/delete spells out which pointer conceptually changed, reinforcing that a linked list mutation is a small, local, constant-size edit to the chain rather than a bulk rewrite.

Traversal: highlighting the walk one .next hop at a time

traverse() walks the rendered .node-wrap elements in order, applying an .active class to each node box (scaling it up and coloring it indigo) for 420ms, then downgrading it to a .found green state and lighting up the arrow leading to the next node in amber, before moving on. This sequence — highlight current node, light the outgoing arrow, move to next node — is a literal animation of the traversal loop while (node !== null) { visit(node); node = node.next; }, making the O(n) nature of searching a linked list (you must walk from the head; there's no random-access jump to index 5) visible rather than assumed.