The Weisfeiler-Lehman (WL) test is a graph isomorphism heuristic that iteratively refines node colorings by aggregating the colors of neighboring nodes. Starting with identical initial labels based on node features, each iteration hashes a node's current color with the multiset of its neighbors' colors to produce a new, more discriminative label. Two graphs are deemed isomorphic if their color histograms remain identical across all iterations.
Glossary
Weisfeiler-Lehman Test

What is Weisfeiler-Lehman Test?
The Weisfeiler-Lehman test is a classical iterative algorithm for graph isomorphism testing that establishes the theoretical upper bound for the discriminative power of message-passing neural networks.
The WL test is foundational to graph neural network (GNN) theory because it defines the ceiling of expressiveness for standard message-passing architectures. A GNN is at most as powerful as the 1-WL test in distinguishing non-isomorphic graphs, a limitation formalized by the Graph Isomorphism Network (GIN). This equivalence means GNNs cannot distinguish certain substructures, such as counting triangles, unless augmented with higher-order features or positional encodings.
Key Characteristics of the WL Test
The Weisfeiler-Lehman test is a classical algorithm that iteratively refines node labels based on neighborhood aggregation, establishing the theoretical upper bound for the discriminative power of message-passing neural networks.
Iterative Color Refinement
The core mechanism involves iteratively updating node labels by hashing the multiset of a node's own label and its neighbors' labels. In each iteration, nodes with identical local structures are assigned the same new color. This process continues until the coloring stabilizes or a predefined number of iterations is reached. The final color histogram serves as a graph-level fingerprint for isomorphism testing.
1-WL vs. k-WL Hierarchy
The standard WL test, known as 1-WL, aggregates only immediate neighbors and fails on regular graphs. Higher-order variants, such as k-WL, color k-tuples of nodes to capture more complex structural patterns. The k-WL hierarchy defines a strict expressiveness ladder: 1-WL < 2-WL < 3-WL, with 3-WL being strictly more powerful than 2-WL. This hierarchy directly maps to the theoretical capacity of higher-order GNNs.
Failure Cases: Regular Graphs
The 1-WL test fails to distinguish any two d-regular graphs with the same number of nodes. For example, a hexagon and two disconnected triangles are non-isomorphic but receive identical color histograms. This failure occurs because every node in a d-regular graph has exactly d neighbors, making all local multisets identical. This limitation defines the expressiveness ceiling for standard message-passing GNNs like GCN and GraphSAGE.
Injectivity of the Aggregation Function
For a GNN to match the 1-WL test's power, its aggregation and update functions must be injective. The Graph Isomorphism Network (GIN) achieves this by using a sum aggregator combined with a multi-layer perceptron: h_v = MLP((1 + ε) * h_v + Σ h_u). Mean and max aggregators fail injectivity, as they cannot distinguish multisets with identical averages or maximums but different distributions.
WL Subtree Kernel
The WL test forms the basis of the Weisfeiler-Lehman subtree kernel, a widely used graph kernel for comparing graphs. It computes the inner product of the color histograms from each iteration, effectively measuring structural similarity. This kernel is computationally efficient and has been a strong baseline for graph classification tasks, directly inspiring the design of early graph neural network architectures.
Connection to GNN Expressiveness
The seminal theoretical result by Xu et al. (2019) proved that message-passing GNNs are at most as powerful as the 1-WL test. A GNN can achieve 1-WL equivalence if its neighbor aggregation and node update functions are injective. This result provides the theoretical framework for understanding GNN limitations and motivates architectures like GIN, k-GNNs, and subgraph-based networks that surpass the 1-WL bound.
WL Test vs. Message-Passing GNNs
A feature-level comparison between the classical Weisfeiler-Lehman graph isomorphism test and standard message-passing graph neural networks, illustrating why the WL test defines the upper bound of discriminative power.
| Feature | Weisfeiler-Lehman Test | Message-Passing GNN | Higher-Order GNN |
|---|---|---|---|
Core Mechanism | Iterative color refinement via neighbor hashing | Differentiable message aggregation and node update functions | Substructure-based aggregation beyond local neighborhoods |
Graph Isomorphism Detection | |||
Differentiable Learning | |||
Node Feature Utilization | |||
Edge Feature Processing | |||
Distinguishes Regular Graphs | |||
Computational Complexity | O(|E|) per iteration | O(|E|·d) per layer | O(|E|·k) or higher |
Handles Continuous Attributes |
Frequently Asked Questions
Explore the core concepts behind the Weisfeiler-Lehman test, the classical algorithm that defines the theoretical limits of modern graph neural networks.
The Weisfeiler-Lehman (WL) test, also known as the 1-WL test or color refinement algorithm, is a classical iterative algorithm for the graph isomorphism problem—determining whether two graphs are structurally identical. The algorithm works by assigning an initial color (or label) to every node based on its features. In each iteration, it aggregates the colors of a node's neighbors, hashes the node's own color with the multiset of its neighbors' colors, and assigns a new, refined color. This process repeats until the coloring stabilizes. If two graphs produce different color histograms at any iteration, they are provably non-isomorphic. The test is computationally efficient but not complete; it cannot distinguish certain non-isomorphic graphs, such as regular graphs with identical neighborhood structures. The WL test forms the theoretical upper bound for the discriminative power of message-passing neural networks (MPNNs).
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Core concepts that define the theoretical limits and architectural choices in graph neural networks, directly connected to the Weisfeiler-Lehman hierarchy of expressiveness.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us