Index Signatures & Record Types

The plain-language idea

interface Scores {
  [studentName: string]: number;   // index signature
}

const scores: Scores = { Ada: 95, Grace: 88 };
scores.Linus = 76;      // ✅ any string key works
scores.Ada = "A+";      // ❌ value must be a number

An index signature ([key: string]: number) describes an object whose keys aren't individually known in advance, but whose values all share one type — a dictionary, not a fixed record. This is exactly what Record<K, V> (from the utility types lesson) generates for you: Record<string, number> and the index signature above describe the same shape.

interface Scores { [key: string]: number } — any string key is allowed, all values must be number.

BackNext

What people usually miss

Watch out

• An index signature makes every possible string key valid, including ones you never intended — scores.toString still resolves to the real Object.prototype.toString method, not number, which can be a genuine source of confusion since the index signature doesn't override inherited properties.
• noUncheckedIndexedAccess (a stricter, opt-in tsconfig setting) makes indexed access return T | undefined instead of just T — reflecting the real possibility that a given key simply isn't present, which a plain index signature otherwise hides.
• You can combine an index signature with specific known properties, but every named property's type must be compatible with the index signature's value type — { name: string; [key: string]: string } works; { age: number; [key: string]: string } doesn't, since age: number conflicts with the index signature's string values.

Why this matters in interviews

"How would you type an object representing a dictionary of arbitrary key-value pairs, all sharing one value type?" is a common, practical question — index signatures (or the equivalent Record<string, T>) is the direct answer, and knowing noUncheckedIndexedAccess exists shows awareness of the real gap this shape usually hides.