In TypeScript, `Record<string, User>` and `{ [key: string]: User }` describe the same dictionary — so what do the two spellings actually differ in, and when would you reach for `Record`?

## They are the same type when the key is `string` Start with the fact that settles most of the argument. `Record` is defined as `{ [P in K]: T }`, and mapping over `string` produces a string index signature: ```ts type A = Record<string, User>; // { [x: string]: User } type B = { [key: string]: User }; declare const a: A; const b: B = a; // assignable both ways — identical structure ``` So "which is faster", "which is safer", or "which one checks the keys" are all the wrong questions for this pair: there is one type with two spellings. Neither validates anything at runtime, and both are erased. ## Where they genuinely diverge The divergence is about what each **form** can express, not about the resulting type. **Record can take a key set that is not open.** This is the big one. An index signature's key must be `string`, `number`, `symbol`, or a template-literal pattern — it cannot be an arbitrary union of literals, and it cannot be an enum: ```ts type Status = 'draft' | 'live'; type Labels = Record<Status, string>; // { draft: string; live: string } // there is no index-signature spelling of that ``` That is the case where the two tools stop being interchangeable, and it is usually the reason to pick `Record` in the first place: a finite key set gives you required entries and a build break when the union grows. **Record composes.** Because it is an ordinary type expression, it nests inside other utilities and appears inline: ```ts type Sparse = Partial<Record<Status, Handler>>; type Frozen = Readonly<Record<string, Config>>; function merge(base: Record<string, unknown>, patch: Record<string, unknown>) { /* … */ } ``` Writing those with index signatures means declaring a named type first, or repeating the signature at each site. **Record is generic, so the key set can be computed.** `Record<keyof Config, Validator>` forces one validator per field of `Config` and updates itself when `Config` changes. An index signature has no such handle on another type. **The index-signature form can coexist with named members.** This is where the other spelling wins: ```ts interface ApiResponse { status: number; [header: string]: unknown; // named members must be compatible with the index type } ``` A bare `Record` cannot express "these known fields plus a catch-all"; you would need an intersection, which reads worse and behaves less predictably at the excess-property check. Note the rule that comes with it: every declared property's type must be assignable to the index signature's value type, which is why the catch-all above is `unknown` rather than `string`. **Interfaces can be extended and augmented.** If the dictionary type is a public surface others build on, declaring it as an interface with an index signature keeps `extends` and declaration merging available. A type alias built from `Record` supports intersection but not merging. ## The assignability gotcha worth knowing One real difference bites in practice: an **interface** does not get an implicit index signature, but an object **type alias** does. So a value typed by an interface is rejected where `Record<string, unknown>` is expected, while the structurally identical alias is accepted: ```ts interface IUser { id: string } type TUser = { id: string }; declare function log(data: Record<string, unknown>): void; declare const i: IUser; declare const t: TUser; log(t); // ok log(i); // error: Index signature for type 'string' is missing in type 'IUser' ``` The reason is that an interface can be reopened by declaration merging elsewhere, so the compiler will not assume its full member list is known. The usual fixes are to declare the model as a type alias, to widen the parameter to `object` or a generic, or to spread the value at the call site. Candidates hit this constantly when passing a domain model into a logging or serialisation helper typed with `Record<string, unknown>`, and being able to explain *why* it happens is what separates a memorised workaround from understanding. ## Choosing in practice Ask what the key set is. If it is a finite, meaningful set — statuses, roles, feature keys, fields of another type — use `Record` and take the exhaustiveness. If the key set is genuinely open, both spellings give you the same type, so pick by context: `Record<string, T>` inline in a signature or composed with another utility, an interface with an index signature when you are declaring a named shape that carries other members or that other code extends. And whichever you pick, remember that an open key set means the compiler will type a lookup as present even when the key is absent — that risk is identical for both spellings.