In TypeScript, how does typing a value as `Readonly<T>` differ from writing `as const` on the object literal?

## Two different layers of the language The cleanest way to hold these apart is to notice *where each one can be written*. `Readonly<T>` is a generic type. It appears in type positions — in an alias, on a parameter, as a return type — and it takes a type in and gives a type out. It never appears next to a value. `as const` is a const assertion, and it appears in *expression* positions, attached to a literal you are writing right there. You cannot put it in a type alias, and you cannot apply it to a value that arrived from somewhere else, such as a function parameter or a parsed JSON payload. If you do not have a literal in your hand, `as const` is not available to you at all. That asymmetry alone answers most of the question, but the behavioural differences are what an interviewer is usually digging for. ## Difference one: inference width ```typescript const a = { mode: "dark" }; // a.mode is string const b = { mode: "dark" } as const; // b.mode is "dark" type Settings = { mode: string }; const c: Readonly<Settings> = { mode: "dark" }; // c.mode is string ``` By default TypeScript widens a string literal in a mutable property to `string`, on the reasonable assumption you might assign another string later. A const assertion suppresses that widening and keeps the literal type. `Readonly<T>` does nothing of the kind — it maps over a type that already exists, and `T[P]` is whatever it was declared to be. If `Settings` says `mode: string`, then `Readonly<Settings>` says `readonly mode: string`. The literal is gone before the utility ever sees it. This is why `as const` is the tool for deriving a union from a value: `typeof b.mode` is `"dark"`, and `(typeof arr)[number]` over an `as const` array gives you the union of its elements. `Readonly<T>` cannot produce a union out of thin air. ## Difference two: depth `Readonly<T>` maps once over `keyof T` and copies each property type through unchanged, so it is one level deep. A const assertion applies through the whole literal expression, so nested object literals become read-only too and nested array literals become readonly tuples: ```typescript const cfg = { name: "api", db: { host: "localhost", port: 5432 }, tags: ["a", "b"], } as const; // cfg.db.host is "localhost" and read-only // cfg.tags is readonly ["a", "b"] — no push, no index assignment type Cfg = { name: string; db: { host: string }; tags: string[] }; declare const m: Readonly<Cfg>; m.db.host = "x"; // allowed — nested type untouched m.tags.push("c"); // allowed — the property is read-only, the array is not ``` The `tags` line catches people out reliably. `Readonly<Cfg>` makes the *property* `tags` read-only, so you cannot swap in a different array; the value it holds is still a `string[]`, which has `push`. Note the separate case where the array *is* the mapped type: a homomorphic mapped type over an array maps its elements, so `Readonly<string[]>` genuinely is `readonly string[]`. ## Difference three: what you can apply it to ```typescript function render(opts: Readonly<Options>) { /* ... */ } // fine // there is no way to write `as const` in that parameter position ``` Only `Readonly<T>` can express "this function will not mutate its argument" in a signature. And only `as const` can pin down a literal you are authoring. They are not competitors so much as tools for two different jobs that happen to both involve the word "read-only". ## What they share Both are erased. Neither emits a single byte of JavaScript, neither calls any runtime freezing mechanism, and neither protects the object from code that did not go through the checker. A value built with `as const` is a plain, fully mutable JavaScript object once the program is running; the readonly-ness lived only in the compiler. Both are also assignable *out* to mutable types in the usual direction, so a `Readonly<T>` value can be passed where `T` is expected — which quietly launders the guarantee. The exception is arrays: a `readonly string[]` is not assignable to `string[]`, so the tuple half of an `as const` does hold its ground. ## The practical rule Use `as const` at the point of definition, on literals: lookup tables, route maps, permitted-value lists you want a union from. Use `Readonly<T>` in type positions, mostly signatures, to constrain what a function may do with a value it did not create. Reaching for `as const` and expecting it to constrain a parameter, or for `Readonly<T>` and expecting literal types, is the mistake this question is designed to surface.