How to Determine an Object’s Type in Ruby

By the end of this page, you will understand how Ruby identifies object types, when .class is useful, and why methods like is_a? and kind_of? are often better choices in real programs. You will also learn common pitfalls around exact class checks versus inheritance-aware checks.

Ruby is a fully object-oriented language, which means everything is an object. Numbers, strings, arrays, hashes, and even classes themselves are objects.

When you call:

1.class

Ruby returns the object's class:

Integer

So yes, .class is a valid and common way to inspect what class an object belongs to.

However, in Ruby, asking for an object's exact class is not always the best way to answer the real question. Often, what you actually want to know is:

• Can this object be used like a string?
• Is this object a kind of number?
• Does this object behave like an array?

That matters because Ruby supports inheritance. An object may belong to a subclass, but still be usable anywhere its parent class is expected.

For that reason, Ruby programmers often prefer:

obj.is_a?(SomeClass)

or

obj.kind_of?(SomeClass)

These check whether the object is an instance of a class or any subclass of it.

Why this matters

If you compare exact classes using .class == SomeClass, your code can become too strict. It may reject objects that should work perfectly well.

Think of .class like checking someone's official job title.

• .class asks: "What is your exact title?"
• is_a? asks: "Are you part of this broader category of workers?"

For example:

• A Dog might have the exact class Dog
• But it is also an Animal

So:

dog.class == Dog      # exact title
 dog.is_a?(Animal)    # broader category

In real programs, the broader category is often more useful than the exact title.

Core syntax

obj.class
obj.is_a?(SomeClass)
obj.kind_of?(SomeClass)

Example 1: Exact class

value = 1

puts value.class
# Integer

This returns the exact class of value.

Example 2: Check whether an object belongs to a type hierarchy

value = 1

puts value.is_a?(Integer)
# true

puts value.is_a?(Numeric)
# true

puts value.is_a?(Object)
# true

This is often more useful because Integer inherits from Numeric, and all regular Ruby objects inherit from Object.

Example 3: Inheritance example

class Animal
end

class Dog < 


dog = .new

puts dog.


puts dog. == 


puts dog.is_a?()

Consider this Ruby code:

class Animal
end

class Cat < Animal
end

pet = Cat.new

puts pet.class
puts pet.is_a?(Cat)
puts pet.is_a?(Animal)
puts pet.class == Animal

Step by step

1. Ruby defines a class named Animal.
2. Ruby defines a class named Cat that inherits from Animal.
3. pet = Cat.new creates a new object whose exact class is Cat.
4. pet.class returns Cat, because that is the object's exact class.
5. pet.is_a?(Cat) returns true, because pet is a Cat.
6. pet.is_a?(Animal) also returns , because inherits from .

Debugging values

When debugging, .class is very useful:

puts params[:id].class

This helps you see whether you received a String, Integer, Array, or something unexpected.

Input validation

You may want to ensure a method receives a number-like value:

def square(n)
  raise ArgumentError, "Must be numeric" unless n.is_a?(Numeric)
  n * n
end

Working with collections

You might handle arrays differently from single values:

if data.is_a?(Array)
  data.each { |item| puts item }
end

API and JSON processing

Parsed data may contain hashes, arrays, strings, booleans, and numbers. Type checks can help decide how to process each value.

In real Ruby codebases, developers usually combine type inspection with Ruby-style flexibility.

Common patterns

Guard clauses

def process(items)
  return [] unless items.is_a?(Array)

  items.map(&:to_s)
end

This exits early if the input is not usable.

Validation

def set_age(age)
  raise ArgumentError, "age must be an Integer" unless age.is_a?(Integer)
  @age = age
end

Accepting broader categories

def total(number)
  raise ArgumentError unless number.is_a?(Numeric)
  number + 10
end

Using Numeric is often better than only allowing , because it also supports , , and others.

1. Using .class == SomeClass when inheritance matters

Broken approach:

def animal?(obj)
  obj.class == Animal
end

This returns false for subclasses like Dog < Animal.

Better:

def animal?(obj)
  obj.is_a?(Animal)
end

2. Checking exact types too early

Beginners sometimes write code that only accepts one exact class even when several related classes should work.

Too strict:

def add_tax(amount)
  raise "bad type" unless amount.class == Integer
  amount * 1.2
end

Better:

# Exact class
obj.class

# Exact class comparison
obj.class == String

# Class or subclass check
obj.is_a?(String)
obj.kind_of?(String)

# Behavior check
obj.respond_to?(:each)

Quick rules

• .class returns the exact class.
• is_a? and kind_of? include inheritance.
• Prefer is_a? over .class == ... in most type checks.
• Prefer respond_to? when behavior matters more than class.

Examples

1.class                 # Integer
1.is_a?(Integer)        # true
1.is_a?(Numeric)        # true
1.class == Numeric      # false
"hi".respond_to?() 

Is .class the proper way to determine an object’s type in Ruby?

Yes. .class is the correct way to get an object's exact class. But for many checks, is_a? is more useful.

What is the difference between .class and is_a? in Ruby?

.class returns the exact class. is_a? returns true if the object belongs to that class or any subclass.

Should I use kind_of? or is_a??

They are effectively the same for normal use. is_a? is more commonly preferred because it reads more naturally.

Why does .class == ParentClass sometimes return false?

Because .class only checks the exact class. If the object is an instance of a subclass, the comparison to the parent class is false.

Is checking type the Ruby way?

Sometimes, but Ruby often prefers checking behavior with instead of checking exact classes.

• Ruby objects — Understanding that everything in Ruby is an object makes type inspection easier to understand.
• Classes and objects — .class directly relates to how objects are created from classes.
• Inheritance — is_a? makes sense only if you understand parent and child classes.
• Duck typing — Ruby often prefers checking behavior over checking exact type.
• respond_to? — A practical way to test whether an object supports a method.
• NilClass — Useful when learning how nil behaves as an object in Ruby.
• Type checking vs coercion — Real programs often convert values instead of strictly rejecting them.