TypeScript Interface Type Checking: Frequently Asked Questions and Answers

Introduction: Why don't interfaces work at runtime?

Hello, friend! If you've ever written in TypeScript, you've likely encountered this situation: you create a perfect interface, describe all the fields, check types at compile time — and suddenly realize that at runtime, your code behaves as if no interfaces exist. Sound familiar? 🎯

This is one of the most popular questions on Stack Overflow: "Interface type check with TypeScript" — thousands of views, hundreds of answers. And it's no surprise, because TypeScript erases interfaces during compilation. Unlike classes, interfaces are a purely declarative construct for the developer and the compiler. They don't exist in JavaScript.

In this article, we'll figure out how to work around this limitation, learn how to check if an object matches an interface at runtime, and answer the most common questions. Let's go! 🚀

Why do we even want to check interfaces?

Imagine: you receive data from an API, a form, or a WebSocket. You're confident it matches the User interface, but suddenly an object arrives without the email field or with the wrong type. If you don't check — your code will crash with an error. TypeScript interfaces only check during development, not in production. So, runtime checks are necessary.

The Problem: Interfaces don't exist at runtime

In TypeScript, interfaces are "syntactic sugar" for static typing. When you compile your code, interfaces disappear. Here's a simple example:

interface User {\n  name: string;\n  age: number;\n}\n\nconst data: unknown = JSON.parse('{"name": "Alice"}');\nif (data instanceof User) { // ❌ Error! User is an interface, not a class\n  console.log(data.name);\n}

The compiler will say: 'User' only refers to a type, but is being used as a value here. This is the main pitfall for beginners. But don't worry — there are several proven ways to work around this.

Method 1: User-Defined Type Guards

The most popular and elegant way is to write a type guard function. It checks the structure of the object and returns true/false, and TypeScript "understands" that inside the block with true, the object definitely matches the interface.

interface User {\n  name: string;\n  age: number;\n  email?: string; // optional field\n}\n\nfunction isUser(obj: unknown): obj is User {\n  if (typeof obj !== 'object' || obj === null) return false;\n\n  const user = obj as Record<string, unknown>;\n  return (\n    typeof user.name === 'string' &&\n    typeof user.age === 'number' &&\n    (user.email === undefined || typeof user.email === 'string')\n  );\n}\n\n// Usage example\nconst data: unknown = JSON.parse('{"name": "Bob", "age": 30}');\n\nif (isUser(data)) {\n  // Now TypeScript knows that data is a User\n  console.log(data.name.toUpperCase()); // ✅ Works\n}

Pros: full control, types are correctly inferred, easy to extend.
\nCons: need to write manually for each interface (but there are libraries!)

What is obj is User?

This is the type guard syntax. It tells TypeScript: "If the function returns true, then the argument obj can be considered of type User". This is the magic that makes runtime checking useful for static analysis.

Method 2: Using Classes Instead of Interfaces

Classes are the only TypeScript construct that persists in JavaScript. If you need to check the type at runtime, you can replace the interface with a class and check using instanceof.

class User {\n  constructor(\n    public name: string,\n    public age: number,\n    public email?: string\n  ) {}\n}\n\nconst data = new User('Charlie', 25);\nif (data instanceof User) {\n  consol