Fixing Type 'string' Is Not Assignable to Type in TypeScript Union Types

By the end of this page, you will understand why a general string cannot be assigned to a narrower union type like Fruit, how TypeScript treats string literal types, and the safe ways to convert or validate a string before using it as a custom union type.

TypeScript distinguishes between broad types and narrow types.

• string means any possible string value
• "Banana" | "Apple" | "Orange" means only one of those exact strings

Your Fruit type is a string literal union type:

type Fruit = "Orange" | "Apple" | "Banana";

This is narrower than string.

So even if a variable currently contains "Banana", if its type is declared as string, TypeScript must assume it could later contain:

"Grape"
"Car"
"Hello"

Because of that, this is not safe:

let myString: string = "Banana";
let myFruit: Fruit = myString; 

Think of string as a huge box of all labels and Fruit as a small basket that only accepts three labels:

• string box: any label at all
• Fruit basket: only Orange, Apple, or Banana

If someone hands you a value from the huge string box, you cannot just drop it into the Fruit basket unless you check that it is one of the allowed labels.

Another way to think about it:

• string = "I know this is text"
• Fruit = "I know this is one of these exact texts"

TypeScript needs that extra certainty before allowing the assignment.

The main ways to work with this are:

1. Declare the value as Fruit from the start

If the value is known to be valid, give it the narrower type immediately.

type Fruit = "Orange" | "Apple" | "Banana";

let myFruit: Fruit = "Banana";

This works because "Banana" is one of the allowed values.

2. Let TypeScript infer the literal type

If you use const, TypeScript usually keeps the exact literal value.

type Fruit = "Orange" | "Apple" | "Banana";

const myString = "Banana";
const myFruit: Fruit = myString;

Here, myString is inferred as "Banana", not string, so the assignment is valid.

3. Validate the string before assigning

Consider this example:

type Fruit = "Orange" | "Apple" | "Banana";

function isFruit(value: string): value is Fruit {
  return value === "Orange" || value === "Apple" || value === "Banana";
}

const input: string = "Banana";
let selectedFruit: Fruit | undefined;

if (isFruit(input)) {
  selectedFruit = input;
}

Step by step:

1. Fruit is defined as a union of three exact strings.
2. isFruit takes any string.
3. Inside isFruit, the function checks whether the value matches one of the allowed fruit names.
4. input is typed as string, so TypeScript does not assume it is a valid .

String literal union types are common in real applications.

API response statuses

type Status = "idle" | "loading" | "success" | "error";

This prevents invalid states like "done" when your app only supports four known statuses.

User roles

type Role = "admin" | "editor" | "viewer";

You can validate input from a database or request before assigning it to Role.

Configuration values

type Theme = "light" | "dark";

This ensures only supported theme names are used.

Form options

type PaymentMethod = "card" | "cash" | "bank-transfer";

In real codebases, developers usually avoid assigning plain string values directly to narrow union types unless the value is already trusted.

Common patterns

Guard clauses for validation

function parseFruit(value: string): Fruit | undefined {
  if (value !== "Orange" && value !== "Apple" && value !== "Banana") {
    return undefined;
  }

  return value;
}

This pattern is common when processing request data, query parameters, or form input.

Early return for invalid input

function handleFruit(value: string) {
  if (value !== "Orange" && value !== "Apple" && value !== "Banana") {
    throw new Error("Invalid fruit");
  }

  const fruit: Fruit = value;
  console.(fruit);
}

Mistake 1: Declaring a literal as string

let myString: string = "Banana";
let myFruit: Fruit = myString; // Error

Why it happens:

• You told TypeScript this variable can hold any string.

How to avoid it:

• Use const when the value does not change.
• Use Fruit directly if it should always be a valid fruit.

const myString = "Banana";
const myFruit: Fruit = myString;

Mistake 2: Using as Fruit without validation

const input: string = "Grape";
const fruit = input as Fruit;

Why it is dangerous:

type Fruit = "Orange" | "Apple" | "Banana";

Rules

• string is broader than Fruit
• You cannot assign string to Fruit without narrowing
• const x = "Banana" is often inferred as the literal "Banana"
• let x = "Banana" is usually inferred more broadly
• as Fruit bypasses checking and should be used carefully

Safe patterns

Known valid value

const fruit: Fruit = "Banana";

Narrow via inference

const value = "Banana";
const fruit: Fruit = value;

Narrow via validation

Why does TypeScript reject a string that contains "Banana"?

Because the variable is typed as string, which means it could contain any string, not just allowed fruit values.

Can I force the assignment with as Fruit?

Yes, but it only silences TypeScript. It does not validate the actual value at runtime.

What is the safest way to convert a string to Fruit?

Use a type guard or validation function that checks the string before assigning it.

Why does const myString = "Banana" work better than let myString: string = "Banana"?

const usually preserves the exact literal type, while string is a broader type.

When should I use a union type like Fruit?

Use it when only a fixed set of string values is valid, such as statuses, roles, modes, or options.

Does TypeScript validate union types at runtime?

No. TypeScript only checks types during development and compilation. Runtime validation must be written explicitly.

• String literal types — "Banana" is a more specific type than string.
• Union types — Fruit is a union of several allowed literal values.
• Type narrowing — validation lets TypeScript reduce string to Fruit.
• Type guards — custom functions like isFruit safely narrow types.
• Type assertions — as Fruit can override the compiler, but should be used carefully.
• const vs let inference — const often preserves literal types.
• Runtime validation — necessary when values come from users, APIs, or files.