Lesson 12 of 80

Literal Types

Q: What are literal types, and why does TypeScript widen let's inferred type but not const's?

A strong answer covers: A literal type describes one exact value (e.g. the type "success", not the general string); let's type widens to the general type because it could be reassigned; const can't be reassigned so its literal type is preserved; Object literal properties widen even inside a const-bound object, because the property itself is still mutable — as const is the fix.

A type that describes not just 'a string' but one exact string — the mechanism that turns a specific value into something the compiler can check against, and what narrowing is actually narrowing down to.

10 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

`let a = "hello";` versus `const b = "hello";` — what type does each get inferred as?

Both are inferred as the general string typea is widened to string; b keeps the literal type "hello"Both are inferred as the literal type "hello"

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Literal Types

What interviewers actually ask about this, and what a strong answer has to cover.

What are literal types, and why does TypeScript widen let's inferred type but not const's?

A strong answer covers

A literal type describes one exact value (e.g. the type "success", not the general string)
let's type widens to the general type because it could be reassigned; const can't be reassigned so its literal type is preserved
Object literal properties widen even inside a const-bound object, because the property itself is still mutable — as const is the fix

Likely follow-ups

How do literal types relate to narrowing and discriminated unions?
When would you reach for `as const` in real code?
Do literal types work for numbers and booleans, or only strings?

Practice these with the AI interviewer →

The plain-language idea

string describes any string. "success" — as a type, not a value — describes exactly one: the string "success" and nothing else.

let status: "success" | "error" | "loading";
status = "success";   // ✅
status = "done";      // ❌ not one of the allowed literals

A union of literal types is how you express "one of these specific, known values" — far more precise than string, and it's what makes exhaustive switch statements and autocomplete for a specific set of values possible.

Literal types: narrowing string down to exact valuesStep 1 of 3

let x: string = 'GET' — x can be reassigned to ANY string later. Too wide.

The `let`/`const` inference trap

let a = "hello";        // inferred as string (widened) — could be reassigned to anything string-shaped
const b = "hello";      // inferred as "hello" (the literal type) — can never be anything else

TypeScript widens a let's inferred type to the general string/number/boolean, because a let might be reassigned — but a const can't be, so TypeScript keeps the precise literal type. This is exactly why passing an inline object literal's property sometimes needs as const to keep it from widening.

What people usually miss

Watch out

Object literal properties widen even inside a const object — const config = { status: "success" } still infers status: string, not status: "success", because properties of an object are treated as reassignable even if the object binding itself is const. as const is the fix.
This is the actual foundation of discriminated unions — a "discriminant" field only works as a reliable narrowing key because it's a literal type, not a general string.
Literal types work for numbers and booleans too, not just strings — type DiceRoll = 1 | 2 | 3 | 4 | 5 | 6 is a perfectly valid, useful literal union.

Why this matters in interviews

"Why does const config = { status: 'success' } sometimes not narrow the way you'd expect when passed somewhere expecting a literal type?" is a real, common gotcha, and understanding the widening rule (object properties widen regardless of the outer const) is what actually explains it.