Introduction

Object.GetHashCode() provides a default hash code for .NET objects, but its behavior is often misunderstood. The important rule is that the default implementation is identity-based for reference types that do not override it, and it is not something you should treat as a stable business key or persisted value.

What the Default Means for Reference Types

If a class inherits GetHashCode() directly from Object, the runtime gives each instance a hash code based on object identity. Two different instances usually produce different hash codes even if their field values are identical.

Example:

1using System;
2
3class Person
4{
5    public string Name { get; set; } = "";
6}
7
8var a = new Person { Name = "Alice" };
9var b = new Person { Name = "Alice" };
10
11Console.WriteLine(a.GetHashCode());
12Console.WriteLine(b.GetHashCode());
13Console.WriteLine(a.Equals(b));

Because Person does not override equality or hash code behavior, a and b are treated as different objects. That is why the default hash code is appropriate for identity semantics, not value semantics.

What You Should Not Assume

Do not assume the default hash code is:

• unique
• based on the memory address in a portable, documented way
• stable across processes
• suitable for database keys or file storage

Its job is much narrower. It helps hash-based structures such as Dictionary and HashSet work correctly during the current process, given the current equality behavior of the object.

That is why a hash code is not an object id.

Why Overriding Often Matters

If your type uses value-based equality, you should usually override both Equals and GetHashCode together.

Example:

1using System;
2
3class Person
4{
5    public string Name { get; }
6
7    public Person(string name)
8    {
9        Name = name;
10    }
11
12    public override bool Equals(object? obj)
13    {
14        return obj is Person other && Name == other.Name;
15    }
16
17    public override int GetHashCode()
18    {
19        return Name.GetHashCode();
20    }
21}

Now two Person instances with the same Name compare as equal and produce matching hash codes. That consistency is required for correct behavior in hashed collections.

Value Types and Overridden Behavior

The title mentions Object.GetHashCode, but remember that many types do not actually use that raw default at runtime:

• value types can inherit different behavior through ValueType
• built-in framework types such as string override GetHashCode
• records and many generated types provide their own implementations

So the "default implementation" question really matters most for custom reference types that have not overridden the method.

Common Pitfalls

The biggest mistake is overriding Equals without overriding GetHashCode. That breaks the rule that equal objects must return equal hash codes and causes subtle bugs in dictionaries and sets.

Another issue is assuming the default hash code somehow represents the object's contents. For reference types that do not override it, that is not the contract.

Developers also sometimes persist hash codes in storage or logs as if they were durable identifiers. They are not designed for that purpose.

Finally, do not build hash codes from mutable fields unless you truly understand the consequences. If the value changes after the object is inserted into a hash-based collection, lookups can become incorrect.

Summary

• The default Object.GetHashCode() for reference types is identity-based.
• It is useful for current-process hashing, not for durable or semantic identifiers.
• Equal-by-value types should usually override both Equals and GetHashCode.
• Many framework types do not use the raw Object implementation because they override it.
• Never treat a hash code as a guaranteed unique or permanent key.