How to Convert a JSON Object to a TypeScript Class

By the end of this page, you will understand the difference between a plain JSON object and a real TypeScript class instance. You will learn when a simple type assertion is enough, when it is misleading, and how to properly create class instances from JSON when you need class methods or runtime behavior.

TypeScript types exist mainly at compile time, not at runtime. That means when you receive JSON from a REST API, what you actually get is a plain JavaScript object, not an instance of your TypeScript class.

For example, if you define a class like this:

class User {
  name: string;

  getDisplayName() {
    return this.name.toUpperCase();
  }
}

and receive this JSON:

{ "name": "Ava" }

that JSON may have the same properties, but it is still not a User instance. It will not automatically have the class prototype, methods, getters, or constructor behavior.

This distinction matters because there are two different goals:

• Tell TypeScript what shape the object has
• Create a real class instance

A type assertion like this:

const user = json as User;

only tells the TypeScript compiler to treat the object as a User. It does not convert the object into a real User instance.

If your code only needs property access, this may be acceptable. If your code relies on class methods, validation logic, computed properties, or inheritance, you need to actually create an instance.

In real programming, this concept matters whenever you:

• consume API responses
• parse local storage data
• deserialize configuration files
• restore objects with methods after JSON parsing

The key idea is:

• JSON gives you data
• Classes give you behavior

Think of JSON as a cardboard cutout of an object, while a class instance is the real machine.

The cardboard cutout may look correct from the front:

• same property names
• same values
• same nested structure

But it does not contain the moving parts:

• methods
• prototype chain
• constructor setup
• runtime logic

So if you only need to read the labels on the cardboard, a plain object is fine. But if you want to press buttons and use the machine's behavior, you need to build a real instance.

1. Type assertion for plain data

If you only need the object as structured data, you can use a type assertion:

class User {
  id!: number;
  name!: string;
}

const json = { id: 1, name: "Ava" };
const user = json as User;

console.log(user.name); // Ava

This works for property access in TypeScript, but user is still just a plain object.

2. Why methods do not work automatically

class User {
  id!: number;
  name!: string;

  greet() {
    return `Hello, ${this.name}`;
  }
}

const json = { id: 1, name: "Ava" };
const user = json as User;

.(user.); 

Consider this example:

class Product {
  id!: number;
  title!: string;

  label() {
    return `#${this.id} ${this.title}`;
  }
}

const json = { id: 10, title: "Keyboard" };
const product = Object.assign(new Product(), json);

console.log(product.label());

Step by step:

1. class Product defines a class with two properties and one method.
2. json is a plain JavaScript object received from somewhere such as an API.
3. new Product() creates a real class instance.
4. Object.assign(new Product(), json) copies the enumerable properties from json into that instance.
5. The result is an object that contains:

This concept appears often in real applications:

API responses

A frontend fetches users, products, or orders from a REST API. The response is plain JSON. If the app only displays values, plain typed objects are often enough.

Domain models with behavior

If your class contains methods like:

• getFullName()
• isExpired()
• calculateTotal()

then API JSON must be turned into real class instances before those methods can be used.

Local storage/session storage

When saving objects to storage, methods are lost because JSON only stores data. On restore, you may need to rebuild class instances.

Date handling

APIs often send dates as strings. Even if you assign the JSON to a class, a date field will still be a string unless you explicitly convert it.

Validation and business logic

Some projects keep logic inside classes. In those cases, deserialization is important so that runtime objects behave correctly.

In real codebases, developers usually choose one of these patterns:

1. Use interfaces for API data

If the response is only data, many teams use an interface or type instead of a class.

interface UserDto {
  id: number;
  name: string;
}

This is often the simplest option because API responses are plain objects anyway.

2. Map DTOs to domain models

A common pattern is:

• receive JSON as a DTO
• validate or transform it
• convert it to a class instance or richer model

interface UserDto {
  id: number;
  name: string;
}

class User {
  constructor(public id: number, public name: string) {}

  greet() {
    return `Hello, ${this.name}`;
  }
}

function toUser():  {
    (dto., dto.);
}

Mistake 1: Thinking as MyClass creates an instance

Broken example:

class User {
  name!: string;

  greet() {
    return `Hello ${this.name}`;
  }
}

const json = { name: "Ava" };
const user = json as User;

user.greet();

Problem:

• user is still a plain object
• greet() does not actually exist at runtime

Avoid it by creating an instance:

const user = Object.assign(new User(), json);

Mistake 2: Using classes when an interface is enough

If the object is only data, a class may add unnecessary complexity.

Better:

  {
  : ;
  : ;
}

 :  = json;

// Plain JSON object from API
const json = await response.json();

// Type assertion: compile-time only
const user = json as User;

// Real instance for flat objects
const user = Object.assign(new User(), json);

// Nested conversion pattern
const user = Object.assign(new User(), {
  ...json,
  address: Object.assign(new Address(), json.address)
});

Key rules:

• as MyClass does not instantiate a class
• JSON from APIs is a plain object
• Use an interface or type if you only need data

Can I cast JSON directly to a TypeScript class?

You can use a type assertion, but it only affects TypeScript's static checking. It does not create a real class instance at runtime.

Why does as MyClass not give me class methods?

Because the original object is still a plain JavaScript object. It does not inherit from your class prototype.

What is the simplest way to convert JSON to a class instance?

For simple flat objects, use:

const obj = Object.assign(new MyClass(), json);

Should I use a class or an interface for API responses?

If the response is just data, an interface or type is usually the better choice. Use a class when you need methods or domain behavior.

Does Object.assign handle nested objects automatically?

No. It only copies top-level properties. Nested objects remain plain objects unless you convert them too.

What about arrays of objects?

Map each item:

const users = jsonArray.map(item => Object.assign(new User(), item));

Is manual mapping ever better?

• Type assertions - Related because as SomeType is often confused with runtime conversion.
• Interfaces in TypeScript - Useful when describing API response shapes without needing class instances.
• Classes in TypeScript - Important for understanding methods, constructors, and runtime behavior.
• Object.assign() - Common way to copy JSON properties into a class instance.
• Type guards - Help validate unknown API data before using it.
• JSON parsing - Relevant because parsed JSON becomes plain JavaScript objects.
• DTOs (Data Transfer Objects) - Common pattern for representing API data before mapping to domain models.
• Serialization and deserialization - Directly related to turning data into runtime objects and back.