When the compiler forgets what your data is
You are building a plugin system. Each plugin returns a Box<dyn Any> containing its configuration. At runtime, your host application receives that box and needs to decide whether to deserialize it as JSON, validate it against a schema, or pass it straight to a database driver. The type information vanished when the value was boxed behind a trait object. Rust erased it on purpose to keep vtables small and dispatch fast. But you still need to know what you are holding.
That is where TypeId steps in. It is the standard library's way of asking "what concrete type is this?" without paying the cost of string parsing or reflection. You get a unique fingerprint for a type, compare fingerprints at runtime, and route your logic accordingly.
What TypeId actually does
Rust's type system lives entirely at compile time. Once the binary is built, the compiler's knowledge of String, Vec<u8>, or your custom DatabaseConfig struct is gone. The runtime only sees memory layouts and function pointers. TypeId bridges that gap by generating a deterministic identifier for any type that implements the Any trait.
Think of it like a library barcode. The book itself contains pages, not a barcode. The barcode is stamped onto the cover so the scanner can look it up in a catalog. TypeId does not store the type's name, its fields, or its methods. It stores a u128 hash derived from the type's internal name and layout metadata. That hash is unique within a single compiled binary. Two TypeId values are equal if and only if they represent the exact same concrete type.
The Any trait is the contract that makes this possible. Any is implemented for every type that is Sized and does not contain unsized fields. By requiring Any, the standard library guarantees that the type has a stable identity that can be exposed at runtime. Without Any, the compiler refuses to generate a TypeId.
The static path: comparing known types
When you know both types at compile time, you do not need trait objects. You can compare TypeId values directly. This is useful for debugging, logging, or writing generic utilities that need to verify type assumptions.
use std::any::TypeId;
/// Returns true if T and U share the same runtime identity.
fn types_match<T: 'static, U: 'static>() -> bool {
// TypeId::of::<T>() is evaluated at compile time.
// It returns a struct wrapping a u128 hash.
let id_t = TypeId::of::<T>();
let id_u = TypeId::of::<U>();
// Equality comparison checks the underlying u128.
// This is a single integer comparison, no string parsing.
id_t == id_u
}
fn main() {
// String and String obviously match.
assert!(types_match::<String, String>());
// String and Vec<u8> are different types.
assert!(!types_match::<String, Vec<u8>>());
println!("Static type comparison works as expected.");
}
The TypeId::of::<T>() function is a const function. The compiler bakes the hash directly into your binary. You never pay a runtime cost to generate it. You only pay when you compare two values, which is just a u128 equality check.
Keep the comparison in one place. The community convention is to wrap TypeId checks in a small helper function rather than scattering TypeId::of::<T>() == other.type_id() across your codebase. It keeps the intent readable and makes future refactoring easier.
How the runtime resolves it
Static comparison is straightforward. The interesting part happens when you only have a trait object. Trait objects erase the concrete type, but they preserve a virtual function table. The Any trait adds a single method to that vtable: fn type_id(&self) -> TypeId.
When you cast a value to &dyn Any, the compiler inserts a pointer to that vtable. Calling .type_id() on the trait object performs a single virtual dispatch. The vtable function returns the precomputed u128 hash for the concrete type. No string allocation, no reflection overhead, no heap traversal.
use std::any::{Any, TypeId};
/// Extracts the TypeId from a trait object and compares it.
fn check_dynamic_type(value: &dyn Any, target: TypeId) -> bool {
// The trait object's vtable contains the type_id function.
// This is a single virtual call, extremely fast.
let actual = value.type_id();
// Compare the runtime hash against the target hash.
actual == target
}
fn main() {
let message = String::from("runtime payload");
// Cast to &dyn Any to access the vtable method.
let boxed: &dyn Any = &message;
// Get the compile-time hash for String.
let string_id = TypeId::of::<String>();
// Verify the dynamic value matches the static expectation.
let matches = check_dynamic_type(boxed, string_id);
println!("Dynamic check passed: {}", matches);
}
The &dyn Any cast is the bridge. You cannot call .type_id() on a String directly because String does not expose that method in its public API. The trait object forces the compiler to route through the Any vtable, which is where the runtime identity lives.
Realistic pattern: routing trait objects
In practice, you rarely compare TypeId values manually. You use them to build type-safe routers, serialization dispatchers, or plugin registries. The pattern usually looks like a match on TypeId or a lookup in a hash map.
use std::any::{Any, TypeId};
use std::collections::HashMap;
/// A simple registry that maps TypeId to a string label.
struct TypeRegistry {
// HashMap uses TypeId as the key.
// TypeId implements Hash and Eq, making it perfect for maps.
labels: HashMap<TypeId, &'static str>,
}
impl TypeRegistry {
/// Creates a new empty registry.
fn new() -> Self {
Self {
labels: HashMap::new(),
}
}
/// Registers a label for a specific type.
fn register<T: 'static>(&mut self, label: &'static str) {
// Insert the compile-time TypeId into the map.
self.labels.insert(TypeId::of::<T>(), label);
}
/// Looks up the label for a dynamic value.
fn resolve(&self, value: &dyn Any) -> Option<&'static str> {
// Fetch the runtime TypeId from the trait object.
let id = value.type_id();
// Look up the label. Returns None if the type is unregistered.
self.labels.get(&id).copied()
}
}
fn main() {
let mut registry = TypeRegistry::new();
registry.register::<String>("text payload");
registry.register::<Vec<u8>>("binary blob");
let text = String::from("hello");
let binary = vec![1, 2, 3];
// Resolve labels at runtime using trait objects.
println!("Text is: {:?}", registry.resolve(&text));
println!("Binary is: {:?}", registry.resolve(&binary));
}
This pattern scales well. You avoid giant if/else chains or fragile string comparisons. The HashMap lookup is O(1). The TypeId key is cheap to hash and compare. You get type-safe registration at compile time and fast dispatch at runtime.
Do not store TypeId values across process boundaries. The hash is deterministic only within a single binary. If you serialize a TypeId to disk and load it in a different build, the hash might change. Treat TypeId as an in-memory routing token, not a persistent identifier.
Where it breaks and what the compiler says
TypeId has strict boundaries. It only works for types that are Sized and implement Any. Slices, trait objects, and dynamically sized types do not get a TypeId. The compiler enforces this with a trait bound check. If you try to call TypeId::of::<[u8]>(), you get E0277 (trait bound not satisfied). The error message points out that [u8] does not implement Sized, which is a prerequisite for Any.
use std::any::TypeId;
fn main() {
// This fails at compile time.
// Slices are dynamically sized and cannot have a TypeId.
let _id = TypeId::of::<[u8]>();
}
The compiler rejects this immediately. You cannot work around it by wrapping the slice in a Box. TypeId::of::<Box<[u8]>>() works, but it gives you the TypeId for Box<[u8]>, not for the slice itself. The wrapper type becomes the identity.
Cross-crate boundaries are another landmine. If crate A defines struct Config {} and crate B also defines struct Config {}, their TypeId values will differ. Even if crate B re-exports crate A's Config, name mangling and compilation units can produce different hashes. The standard library documentation explicitly warns against comparing TypeId across crate boundaries. If you need cross-crate type identity, use a shared marker trait or a string-based type name instead.
You also cannot recover the type name from a TypeId. The u128 hash is one-way. If you need a human-readable name for logging or debugging, use std::any::type_name::<T>(). That function returns a &str, but it is not guaranteed to be stable across compiler versions or optimization levels. Use it for diagnostics only. Never parse it for routing logic.
Treat TypeId as a routing token, not a reflection API. It answers one question: "Is this the exact same type?" It does not answer "What are the fields?" or "How do I construct it?"
When to reach for TypeId
Use TypeId when you need fast, zero-allocation type comparison inside a single binary. Use TypeId when you are building a registry, dispatcher, or plugin system that routes &dyn Any values to type-specific handlers. Reach for Any::downcast_ref when you need to extract the concrete value after confirming the type, rather than storing and comparing TypeId manually. Pick a custom enum or a sealed trait when you want the compiler to enforce exhaustiveness at compile time instead of handling unknown types at runtime. Use std::any::type_name when you need a human-readable label for logs or error messages, but never for control flow. Trust the borrow checker and the type system first. Fall back to runtime type identification only when dynamic dispatch is unavoidable.