<pre><code class="language-text">Attention! This article has been edited with the help of AI. If that fact makes you twitch or you have a personal grudge against AI, if you’re worried it might bruise your fragile soul, if you’re dead sure Skynet started the same way, or if your backside is already overheating - just stop here. Go meditate, bake a pie, or yell at some clouds instead. Preserve your inner peace and channel that energy into something useful. Thanks!
</code></pre>
Ever stared at a TypeScript file and thought: “Wait… why did I just use <code>type</code> here instead of <code>interface</code>?” Yeah. Me too. And honestly? It’s not always obvious. Feels like choosing between ketchup and mustard on a hot dog — both kinda work, but someone out there will judge you hard.
Let’s cut through the noise. No fluff. Just real talk, weird analogies, and a few hot takes. We’re diving into the Type vs Interface tango in TypeScript. Not the textbook way. The way — like explaining quantum physics using pizza toppings.
<hr>
Imagine you’re building a Lego city. 
<code>interface</code>? That’s your modular Lego baseplate. You snap pieces together. Want to extend a house? Just click another block on top. Need a balcony? Attach it. Tomorrow? Add solar panels. It’s open-ended. Evolves. Grows. Like a Tamagotchi, but less tragic when you forget it.
Now <code>type</code>? That’s your custom 3D-printed Lego piece. Precise. Sharp edges. Does exactly what you designed. But once it’s printed? No modifications. Want changes? Recreate the whole thing. Brutal. Efficient. Final.
That’s the vibe.
<hr>
<h3>So What’s the Real Difference?</h3>
Let’s not sugarcoat it — in 90% of cases, they do almost the same thing. You can define object shapes, functions, even unions. But the devil’s in the details. And TypeScript’s devil wears Prada and judges your code style.
<h4>1. Extensibility: The Big One</h4>
<code>interface</code> can be reopened. Like a restaurant that closes at 3 PM and magically reopens at 7 with a new menu.
<pre><code class="language-ts">interface Cat {
 meow: () =&gt; string;
}

// Later, somewhere else in your code...
interface Cat {
 purr: () =&gt; string;
}

// Boom. Cat now has both meow AND purr.
// TypeScript just… merged them. No drama.
</code></pre>
Try that with <code>type</code>? Nope. Compiler throws a fit. “Cannot redeclare ‘Cat’”. It’s a one-shot deal. Like a tattoo you regret at 2 AM.
<pre><code class="language-ts">type Dog = {
 bark: () =&gt; string;
};

type Dog = {
 wagTail: () =&gt; void;
}; // ❌ Error. TypeScript says: &quot;Nah, bro. Pick one.&quot;
</code></pre>
So if you’re building a library, or expect your types to evolve across files? <code>interface</code> is your BFF.
<hr>
<h4>2. Flexibility in Shape</h4>
<code>type</code> doesn’t play by the same rules. It’s… wilder. Can represent unions, tuples, mapped types, conditional types — stuff <code>interface</code> just can’t handle.
<pre><code class="language-ts">type Status = &#x27;loading&#x27; | &#x27;success&#x27; | &#x27;error&#x27;;
type Coordinates = [number, number];
type Maybe&lt;T&gt; = T | null | undefined;
</code></pre>
Try doing that with <code>interface</code>? Good luck. You’ll end up with 17 interfaces and a therapist.
<code>interface</code> is strict. It likes objects. It likes structure. It drinks black coffee and reads the spec before bed.
<code>type</code>? It’s the one at the party doing handstands on the couch, yelling, “I can be a string OR a function OR a recursive tree — deal with it!”
<hr>
<h4>3. Merging vs. Intersection</h4>
<code>interface</code> merges automatically. Like two rivers joining.
<pre><code class="language-ts">interface User {
 id: number;
}

interface User {
 name: string;
}

// User now has id + name. Magic? Or just TypeScript being slick?
</code></pre>
<code>type</code>? No merging. But you can intersect:
<pre><code class="language-ts">type Id = { id: number };
type Name = { name: string };
type User = Id &amp; Name; // Same result, but manual work.
</code></pre>
It’s like building a sandwich. <code>interface</code> hands you a fully stacked one. <code>type</code> gives you ingredients and a knife. You do the slicing.
<hr>
<h4>4. Performance &amp; Tooling</h4>
Here’s a spicy take: interfaces are slightly better for large-scale projects. Why? Because TS can optimize them. Faster autocomplete. Smoother refactoring. Less “TS Server is thinking…” moments.
Types? They’re heavier. Especially complex unions. Can slow down IDEs. Not a dealbreaker. But if you’re working on a codebase the size of a small moon? Every millisecond counts.
<hr>
<h3>So… What Should You Use?</h3>
Let’s get real. There’s no one answer. But here’s my rule of thumb — forged in fire, broken builds, and late-night debugging:
<blockquote>
Use <code>interface</code> for public APIs, objects, and things that might grow. 
Use <code>type</code> when you need flexibility — unions, tuples, or complex logic.
</blockquote>
Examples?
✅ Go for <code>interface</code>:
<ul>
<li>Shapes of objects (users, config, API responses)</li>
<li>Classes implementing contracts</li>
<li>Libraries or shared code</li>
<li>Anything you might extend later</li>
</ul>
✅ Go for <code>type</code>:
<ul>
<li>Union types (<code>'dark' | 'light'</code>)</li>
<li>Tuples (<code>[string, number]</code>)</li>
<li>Function signatures with overloads</li>
<li>Conditional or mapped types</li>
<li>When you need <code>&amp;</code> or <code>|</code> in the definition</li>
</ul>
And hey — don’t overthink it. If you’re just starting? Pick <code>interface</code> for objects. It’s safer. More predictable. Like wearing socks with sandals — functional, even if not trendy.
<hr>
<h3>A Few Curveballs</h3>
You can extend an <code>interface</code> from a <code>type</code> — but only if the type is object-like.
<pre><code class="language-ts">type Animal = { sound: string };
interface Dog extends Animal { breed: string; } // ✅ Works
</code></pre>
But not the other way around if the type uses unions or primitives.
And <code>type</code> can mimic <code>interface</code> using <code>&amp;</code>, but it’s clunkier. Like using duct tape to fix a Rolex.
<hr>
<h3>Final Thoughts?</h3>
It’s not about which is better. It’s about fit.
Think of <code>interface</code> as a well-tailored suit — clean, structured, meant to be built upon. 
<code>type</code>? That’s your Swiss Army knife. Not pretty, but damn useful when things get weird.
Use both. Respect both. And for the love of linting, don’t religiously stick to one. That way lies madness.
Oh, and if your teammate insists <code>interface</code> is always superior? Ask them to define a union with it… then walk away slowly.

Coffee Mug

Anatoly Nevzorov

Explores the key differences between TypeScript's `type` and `interface` keywords. Covers extensibility (interfaces can be reopened and merged, types cannot), flexibility (types handle unions and complex structures better), performance considerations, and practical usage guidelines. Recommends using interfaces for object shapes and extensible APIs, and types for unions, tuples, and complex type logic.

What’s the difference between Type and Interface in TypeScript?

I enjoyed the informal style of explaining the diffs between them, but I still couldn’t quite grasp it. I truly believe that, in my case, <code>type</code> will always serve <s>the</s> my purpose.

Great article, love the way this is written!

Everyone is complimenting that writing style, but it very strongly reminds me of ChatGPT. Did you write this on your own or did you use help? :)

Great piece. However, I found it rather hard to relate to the lego analogy

7+ years in JS/TS land - And this is the best explanation I’ve seen throughout! Kudos 🎉🔥
Nicely summarized at the end -
<code>Use interface for public APIs, objects, and things that might grow. Use type when you need flexibility — unions, tuples, or complex logic.</code>