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)        # => true

Why this matters

In real programs, you often care about whether an object can be treated like a broader category, not whether it was created from one exact class.

For example:

• A Dog should be acceptable anywhere an Animal is expected.
• A custom exception class should still count as an Exception.
• A subclass of String may still be usable where a String-like object is acceptable.

That is why kind_of? and is_a? are usually more flexible and more useful than instance_of?.

kind_of? vs is_a?

In Ruby, kind_of? and is_a? behave the same way. is_a? is effectively an alias of kind_of?.

So this:

obj.kind_of?(String)
obj.is_a?(String)

means the same thing.

The choice between them is mostly about readability and style.

Why Ruby has both

Ruby often provides multiple method names when they read well in different contexts.

For example:

• user.is_a?(Admin) reads like plain English.
• value.kind_of?(Numeric) can also read naturally.

Ruby favors expressive code, so both names exist even though they do the same job.

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 false because car was not created directly from Vehicle.
• kind_of?(Vehicle) and is_a?(Vehicle) are true because Car inherits from Vehicle.

Example with built-in classes

number = 10

puts number.instance_of?(Integer) # true
puts number.kind_of?(Integer)     # true
puts number.is_a?(Numeric)        # true

Here, 10 is exactly an Integer, but Integer is also part of Ruby's numeric hierarchy, so 10.is_a?(Numeric) is also true.

Example with modules

kind_of? and is_a? also return true for included modules.

module Drivable
end

class Car
  include Drivable
end

car = Car.new

puts car.is_a?(Drivable) # true

This is another reason instance_of? is stricter: it checks exact class, not inherited behavior or included modules.

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

dog = Dog.new

Now dog is an object created directly from the Dog class.

4. Check exact class

dog.instance_of?(Animal)

Ruby asks: "Was this object created from the Animal class exactly?"

Answer: no. It was created from Dog.

Result:

false

5. Check broader type relationship

dog.is_a?(Animal)

Ruby asks: "Can this object be treated as an Animal because it is in that inheritance chain?"

Answer: yes. Dog inherits from Animal.

Result:

true

Final output

false
true

That small difference is the main reason these methods exist separately.

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?(String)
    raise ArgumentError, "Must be a plain String"
  end

  value
end

This rejects subclasses of String.

4. Module-based capability checks

module Serializable
end

class Report
  include Serializable
end

def save(obj)
  if obj.is_a?(Serializable)
    puts "Saving object"
  end
end

This works because is_a? recognizes included modules.

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
end

Module and interface-style design

Ruby often relies on behavior instead of exact types. In many codebases, developers prefer duck typing over class checks.

def render(item)
  if item.respond_to?(:to_html)
    item.to_html
  else
    item.to_s
  end
end

This is often more Ruby-like than checking is_a?.

When instance_of? appears

instance_of? is mostly used when:

• exact class identity matters
• a subclass would behave incorrectly
• tests or framework internals need strict matching

For everyday application code, is_a? is more common.

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
end

2. Thinking kind_of? and is_a? are different

They are not different in behavior.

obj.kind_of?(String) == obj.is_a?(String) # true

Choose one style and stay consistent.

3. Forgetting that modules also work with is_a?

module Flyable
end

class Bird
  include Flyable
end

Bird.new.is_a?(Flyable) # true

Beginners sometimes expect only classes to work here.

4. Overusing type checks instead of duck typing

Less Ruby-like:

def print_name(user)
  if user.is_a?(User)
    puts user.name
  end
end

Often better:

def print_name(obj)
  if obj.respond_to?(:name)
    puts obj.name
  end
end

This focuses on behavior instead of class.

5. Assuming exact class checks are safer by default

Stricter is not always better. Exact checks can make code harder to extend and reuse.

Use instance_of? only when exact class identity is truly required.

kind_of? vs is_a?

is_a? vs duck typing

In idiomatic Ruby, behavior checks are often preferred when possible.

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?(Animal) # false
dog.is_a?(Dog)           # true
dog.is_a?(Animal)        # true
dog.kind_of?(Animal)     # true

Module example

module Runnable; end

class Person
  include Runnable
end

Person.new.is_a?(Runnable)    # true
Person.new.kind_of?(Runnable) # true

Good default

• Usually prefer is_a?
• Use instance_of? only for strict exact-class checks
• Consider respond_to? when you care about behavior instead of type

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, respond_to? may be a better fit.

Can subclasses fail an instance_of? check?

Yes. instance_of? only returns true for the exact class, not parent classes or subclasses.

• 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.