Interfaces vs Type Aliases
Understand the practical differences between interface and type, and when to reach for each one.
Reading Time
12 min
Lesson
Lesson 18 of 30
They Overlap a Lot
For describing simple object shapes, interface and type are nearly interchangeable — either works, and the choice mostly comes down to a few specific differences and team convention.
Equivalent Object Shapes
interface UserInterface {
name: string;
age: number;
}
type UserType = {
name: string;
age: number;
};Declaration Merging (Interfaces Only)
Multiple interface declarations with the same name automatically merge into one — a feature unique to interfaces, often used to extend types from external libraries.
Declaration Merging
interface User {
name: string;
}
interface User {
age: number;
}
// User is now merged: { name: string; age: number }
const user: User = { name: "Alice", age: 30 };type Can Describe More Than Object Shapes
type can name unions, intersections, tuples, and primitives directly — things an interface cannot represent on its own.
Only type Can Do This
type ID = string | number; // union
type Point = [number, number]; // tuple
type Handler = () => void; // function typeFeature Comparison
| Feature | interface | type |
|---|---|---|
| Object shapes | Yes | Yes |
| extends another | Yes (extends) | Yes (via &) |
| Declaration merging | Yes | No — duplicate names error |
| Unions / tuples / primitives | No | Yes |
| Implemented by a class | Yes | Yes |
A Common Convention
Many teams use interface for object shapes and class contracts (taking advantage of declaration merging and extends), and type for everything else — unions, tuples, and utility compositions.
Best Practice
Pick one convention for your team and apply it consistently. The functional differences rarely matter for simple object shapes — consistency across a codebase matters more than which one you chose.