Object#kind_of?

obj.kind_of?(klass) -> true or false

Returns boolean· Updated May 30, 2026· Core Classes

typesclassobjectchecking

kind_of? is a Kernel method that checks whether an object is an instance of a given class or any of its ancestor classes. It’s functionally identical to is_a? — the two are aliases, and the choice between them is purely stylistic.

Syntax

obj.kind_of?(klass)

Parameters

Parameter	Type	Description
`klass`	`Class` or `Module`	The class or module to check against

The method accepts a class or a module and walks the entire ancestry chain. This means an object can be checked against any ancestor, not only its immediate class. The result is always a boolean, which makes the method a clean fit for guard clauses and conditional branching.

Examples

Basic type checking

"hello".kind_of?(String)
# => true

"hello".kind_of?(Object)
# => true (String is a subclass of Object)

"hello".kind_of?(Integer)
# => false

These first checks show the basic shape of the method. The method checks the full class tree you ask about, not only the immediate class. If the object sits anywhere in that ancestry, the answer is true. That is what makes kind_of? useful in code that accepts more than one related type.

Checking superclasses

42.kind_of?(Integer)
# => true

42.kind_of?(Numeric)
# => true (Numeric is a superclass of Integer)

42.kind_of?(Object)
# => true (Object is the root class)

Superclass checks are where the method starts to feel more like a hierarchy question than a strict type test. Ruby walks the ancestry chain for you, so the code can ask about a broader family of objects without manual branching. That keeps guard clauses short and readable.

Checking included modules

[1, 2, 3].kind_of?(Enumerable)
# => true

The module example matters because Ruby classes often include behavior through modules as well as inheritance. If your code works with collections or shared interfaces, checking against a module can be a clean way to express that the object supports the methods you need.

When to use kind_of? vs is_a?

There’s no functional difference. Use whichever reads better in context:

# Both are equivalent:
item.is_a?(String)
item.kind_of?(String)

Some developers prefer is_a? for type checking (it reads as “is a string”) and kind_of? when they want to emphasize the class hierarchy. Pick one and stay consistent across the codebase.

Either spelling works identically at runtime, so the choice is about readability, not behavior. What matters is that the team agrees on one convention and sticks to it, because mixing both in the same file can suggest a difference that does not exist. That way readers do not have to pause and wonder whether one form carries a different meaning. The clarity comes from the type relationship itself, not from the alias you picked.

Practical Notes

kind_of? is a good fit when a method can accept a family of related types instead of one exact class. That often shows up in parsing code, serializers, and service objects where the input may be a string, a numeric type, or a collection. The method reads well in guard clauses because it makes the accepted shape of the input explicit.

For broader checks, modules matter too. Since Ruby classes can include modules, kind_of? can reflect that wider ancestry tree rather than only the immediate class. That is one reason it appears frequently in code that needs to work with polymorphic objects.

Common Patterns

Guard clauses

def process(data)
  return unless data.kind_of?(Hash)
  # ...
end

A guard clause with kind_of? makes the expected input shape explicit right at the top of the method. If the wrong type arrives, the method exits early without reaching the main logic. This keeps the happy path clean and the type contract visible.

Case statements

case object
when String then object.upcase
when Array then object.join
end

Ruby’s case statement uses the === operator for comparison, which works naturally with classes. Writing when String is equivalent to String === object, and it reads as cleanly as a chain of kind_of? checks. For a small number of known types, this pattern is often more readable than an if-elsif chain.

Errors

Passing a non-Class raises TypeError:

"test".kind_of?("string")
# => TypeError: class or module required

The error case is worth seeing because it reinforces the contract of the method. kind_of? expects a class or module, not a string name, so the check stays tied to real Ruby types. That keeps the call honest and prevents accidental guesswork at runtime.