Ruby kind_of? vs instance_of? vs is_a?: Differences and When to Use Them

By the end of this page, you will understand how Ruby checks an object's type, how inheritance affects kind_of? and is_a?, why instance_of? is stricter, and which method is usually the best choice in everyday Ruby code.

Ruby objects belong to classes, and classes can inherit from other classes. Because of that, there is more than one way to ask what an object "is".

kind_of? and is_a? check whether an object is an instance of a class or any of its parent classes or included modules.

instance_of? checks whether an object is an instance of exactly one specific class.

Core idea

Suppose you have this inheritance chain:

class Animal
end

class Dog < Animal
end

A Dog object is:

• an instance of Dog
• also a kind of Animal

That means:

dog = Dog.new

dog.instance_of?(Dog)    # => true
dog.instance_of?(Animal) # => false

dog.kind_of?(Dog)        # => true
dog.kind_of?(Animal)     # => true

dog.is_a?(Dog)           # => true
dog.is_a?(Animal)        

Think of classes like family categories.

• instance_of? asks: Who are your exact parents?
• kind_of? / is_a? ask: What family do you belong to?

If a Dog comes from the Dog class, then:

• it is exactly a Dog
• it also belongs to the larger Animal family

So:

• instance_of?(Dog) checks the exact label on the object
• is_a?(Animal) checks the full family tree

A simple analogy:

• instance_of? = exact job title
• is_a? = department or profession category

Someone might be exactly a SeniorBackendEngineer, but they are also a kind of Engineer and a kind of Employee.

Basic syntax

object.instance_of?(ClassName)
object.kind_of?(ClassName)
object.is_a?(ClassName)

Example with inheritance

class Vehicle
end

class Car < Vehicle
end

car = Car.new

puts car.instance_of?(Car)      # true
puts car.instance_of?(Vehicle)  # false

puts car.kind_of?(Car)          # true
puts car.kind_of?(Vehicle)      # true

puts car.is_a?(Car)             # true
puts car.is_a?(Vehicle)         # true

Explanation

• instance_of?(Car) is true because car was created directly from Car.
• instance_of?(Vehicle) is because was not created directly from .

Consider this example:

class Animal
end

class Dog < Animal
end

dog = Dog.new

puts dog.instance_of?(Animal)
puts dog.is_a?(Animal)

Step by step

1. Define Animal

class Animal
end

This creates a class called Animal.

2. Define Dog < Animal

class Dog < Animal
end

This means Dog inherits from Animal.

3. Create a Dog object

1. Accepting subclasses in APIs

If a method expects a general type, use is_a? or kind_of?.

def log_error(error)
  raise ArgumentError, "Expected an exception" unless error.is_a?(Exception)

  puts error.message
end

This allows custom exception subclasses too.

2. Validating objects by category

def print_total(value)
  if value.is_a?(Numeric)
    puts "$#{value}"
  else
    puts "Not a number"
  end
end

This works for integers, floats, and other numeric types.

3. Exact class checks for strict logic

Sometimes you really need the object to be one exact class.

def raw_string_only(value)
  unless value.instance_of?()
     , 
  

  value

In real Ruby codebases, developers often avoid strict type checks unless they are truly necessary.

Common pattern: prefer flexible checks

def process_payment(payment)
  raise ArgumentError, "Invalid payment" unless payment.is_a?(Payment)

  payment.process
end

This allows subclasses such as CreditCardPayment or PaypalPayment.

Guard clauses

Type checks are often used in guard clauses near the top of a method.

def send_notification(user)
  return unless user.is_a?(User)

  # continue safely
end

Error handling

Ruby code often checks broad error categories rather than exact classes.

begin
  risky_operation
rescue => e
  if e.is_a?(StandardError)
    puts e.message
  end

1. Using instance_of? when subclasses should be allowed

Broken approach:

class Animal
end

class Dog < Animal
end

def handle_animal(animal)
  unless animal.instance_of?(Animal)
    raise ArgumentError, "Expected Animal"
  end
end

handle_animal(Dog.new) # raises error

Problem:

• Dog is a valid Animal subtype, but instance_of? rejects it.

Better:

def handle_animal(animal)
  unless animal.is_a?(Animal)
    raise ArgumentError, "Expected Animal"
  end

kind_of? vs is_a?

obj.instance_of?(ClassName)
obj.kind_of?(ClassName)
obj.is_a?(ClassName)

Rules

• instance_of?

  • true only if the object's class is exactly ClassName
  • ignores parent classes
  • ignores included modules

• kind_of?

  • true if object is that class, a subclass, or includes that module

• is_a?

  • same behavior as kind_of?
  • usually chosen for readability

Quick examples

class Animal; end
class Dog < Animal; end

dog = Dog.new

dog.instance_of?(Dog)    # true
dog.instance_of?() 
dog.is_a?()           
dog.is_a?()        
dog.kind_of?()     

What is the difference between kind_of? and is_a? in Ruby?

There is no behavioral difference. is_a? is an alias of kind_of?, so both return the same result.

When should I use instance_of? in Ruby?

Use it when you need to ensure an object belongs to one exact class and not any subclass.

Is is_a? usually better than instance_of??

In many cases, yes. is_a? works better with inheritance and is more flexible in object-oriented code.

Does is_a? work with modules?

Yes. If a class includes a module, is_a?(ThatModule) can return true.

Why does Ruby have both kind_of? and is_a??

Ruby often provides multiple method names for readability. Different names can make code read more naturally in different situations.

Should I avoid type checking in Ruby?

Not always, but many Ruby programs prefer duck typing. If you only need an object to support a method, may be a better fit.

• inheritance — is_a? and kind_of? depend on the class hierarchy.
• modules — included modules also affect is_a? and kind_of? results.
• duck typing — Ruby often prefers checking behavior instead of exact type.
• respond_to? — a common Ruby way to ask whether an object supports a method.
• class — understanding an object's class helps explain instance_of?.
• Object — most Ruby classes inherit from Object, which affects type relationships.
• polymorphism — subclasses being accepted as parent types is a core example of polymorphism.