TypeScript Interface vs Type: Differences and When to Use

For describing the shape of an object, interface and type do the same job, and values of one are assignable to the other when the shapes match. The differences are at the edges: type can name things an interface cannot (unions, tuples, computed types), and an interface can do a few things a type alias cannot (merging, checked extends).

interface PointI {
  x: number;
  y: number;
}

type PointT = {
  x: number;
  y: number;
};

const a: PointI = { x: 1, y: 2 };
const b: PointT = a; // same shape, so they are interchangeable
const c: PointI = b;

function show(p: PointI): string {
  return `(${p.x}, ${p.y})`;
}

console.log(show(b), show(c)); // (1, 2) (1, 2)

TypeScript compares object types by structure, so the name of the declaration does not matter for assignability. What follows is the list of places where the choice does matter.

Comparison Table

What Only type Can Do

Anything that is not a single object shape needs a type alias:

type Status = "idle" | "loading" | "done";                   // union of literals
type Coordinates = [lat: number, lng: number];               // tuple
type Handler = (event: string) => void;                      // function type
type ID = string | number;                                   // union of primitives
type Flags<T> = { [K in keyof T]: boolean };                 // mapped type
type ElementOf<T> = T extends readonly (infer U)[] ? U : T;  // conditional type

const current: Status = "loading";
const here: Coordinates = [51.5, -0.12];
const onSave: Handler = (e) => console.log("saved:", e);
const flags: Flags<{ dark: string; beta: number }> = { dark: true, beta: false };
const first: ElementOf<string[]> = "a";

onSave(current);
console.log(here, flags, first);
// saved: loading
// [ 51.5, -0.12 ] { dark: true, beta: false } a

None of these can be written with interface (the last two are covered in mapped types and conditional types). This is the practical reason every codebase ends up using type somewhere, whatever it uses for object shapes.

What Only interface Can Do: Declaration Merging

Two interface declarations with the same name in the same scope combine into one. Two type declarations with the same name are error TS2300, Duplicate identifier.

interface Settings {
  theme: string;
}
interface Settings {
  fontSize: number;
}
const s: Settings = { theme: "dark", fontSize: 14 }; // needs both

type Options = { a: number };
type Options = { b: number }; // error TS2300: Duplicate identifier 'Options'.

Merging is how library types are extended from outside: adding a property to the global Window, to Express's Request, or to a library's theme type. If you publish types that users may need to augment, use interfaces. In your own application code, an accidental merge (two script files declaring the same global interface name) happens silently unless the two declare the same property with different types, which is one argument some teams give for preferring type.

extends vs Intersection

An interface extends with extends, a type alias with &. They mostly produce the same result, but they handle a conflicting property differently. extends reports the conflict at the declaration:

// This does not compile: id cannot change from string to number
interface Base {
  id: string;
  name: string;
}

interface Broken extends Base {
  id: number;
}

const x: Broken = { id: 1, name: "a" };
console.log(x);

index.ts(7,11): error TS2430: Interface 'Broken' incorrectly extends interface 'Base'.
  Types of property 'id' are incompatible.
    Type 'number' is not assignable to type 'string'.

An intersection accepts the same conflict silently and turns the property into never (a string that is also a number). The error only appears later, when you try to create a value:

type Base = { id: string; name: string };
type Broken = Base & { id: number }; // no error here

// id is string & number, which is never: no object can satisfy Broken
// @ts-expect-error: Type 'number' is not assignable to type 'never'.
const x: Broken = { id: 1, name: "a" };

console.log("the alias compiled; only using it failed");

The error points at the object, far from the declaration that caused it. For building object types from other object types, extends gives the better message.

Index Signatures: an Easy-to-Miss Difference

A type alias for an object type gets an implicit index signature, so it can be passed where a Record<string, unknown> is expected. An interface does not. This is by design: the TypeScript team's explanation (issue #15300 on the TypeScript repository) is that an interface can be augmented by later declarations, so inferring an index signature for it is less safe, and changing the rule now would break too much code.

interface UserI { name: string; age: number }
type UserT = { name: string; age: number };

function logFields(fields: Record<string, unknown>) {
  for (const [key, value] of Object.entries(fields)) {
    console.log(`${key}=${String(value)}`);
  }
}

const t: UserT = { name: "Ada", age: 36 };
const i: UserI = { name: "Alan", age: 41 };

logFields(t); // fine

// @ts-expect-error: Index signature for type 'string' is missing in type 'UserI'.
logFields(i);

logFields({ ...i }); // a spread copy is a fresh object type, so it is accepted

The call marked @ts-expect-error still runs and prints Alan's fields: the rule is a compile-time one. This is the usual reason for a confusing error when an interface value is passed to a logging, serialization or query helper typed with Record<string, ...>. Switch that one declaration to type, spread the value, or type the helper's parameter with an interface or a generic instead.

Performance and Error Messages

The Performance page of the TypeScript wiki (section "Preferring Interfaces Over Intersections") suggests interface Foo extends Bar, Baz { ... } over type Foo = Bar & Baz & { ... } when composing object types. Its reasons: an interface is a single flat object type that detects property conflicts, type relationships between interfaces are cached (intersections as a whole are not), and checking a value against an intersection checks every constituent before the flattened type. The difference matters in large codebases with many composed types; for a few ordinary object shapes you will not measure it.

The same page notes that interfaces display better. An interface is shown by its name in hovers and error messages, while an intersection alias is often printed expanded into its parts, which makes long messages harder to read.

Which One to Use

A rule that works:

1. Object shapes: interface. It gives checked extends, clearer errors on large compositions, and lets library users augment it. This matches the TypeScript handbook's heuristic: "use interface until you need to use features from type".
2. Everything else: type. Unions, tuples, function types, literal types, and anything built with mapped, conditional or template literal types.
3. Exception: use type for an object shape that has to fit Record<string, ...> parameters, or when you deliberately want to prevent merging.

Using type for everything is also a coherent choice, and many codebases do. Mixing both at random is the one option to avoid: it makes readers wonder whether a difference was intended.