as const & satisfies

Exact values, and a check that keeps them

A shop page has two themes, light and dark. A function switches the theme, and it only accepts those two words. The page keeps its settings in an object:

1type Theme = "light" | "dark";2function setTheme(theme: Theme) {3  console.log(`Theme: ${theme}`);4}5 6const settings = { theme: "dark", fontSize: 16 };7//    ^?8setTheme(settings.theme);

Line 1 names the two themes: Theme is "light" | "dark", a union that is exactly one of those two words (the Union types lesson covers |). Lines 2 to 4 make setTheme, which takes a Theme. Line 6 makes the settings, with the theme "dark". Line 8 passes it to setTheme, and TypeScript marks it, on purpose here.

The query on line 7 shows why: theme: string. This is widening, from the Literal types lesson: an object's properties can change later, so TypeScript gives theme the type string instead of the literal type "dark", a type that is one exact value. The message on line 8, Argument of type 'string' is not assignable to parameter of type 'Theme', means "any text might not be one of your two themes". Literal types fixed this with as const after the object:

1type Theme = "light" | "dark";2function setTheme(theme: Theme) {3  console.log(`Theme: ${theme}`);4}5 6const settings = { theme: "dark", fontSize: 16 } as const;7//    ^?8setTheme(settings.theme);

The query on line 7 now shows readonly theme: "dark" and readonly fontSize: 16: exact values that code may read but not change. Line 8 has no error and prints Theme: dark. as const is a type assertion, from the Type assertions lesson, called a const assertion: instead of naming a type, it says "keep this value exactly as it is".

That's the recap. This lesson goes further in two directions:

• Where as const can go, and how far down it reaches: nested objects, lists, and lists you pass to functions.
• satisfies, which checks a value against a type and keeps its exact values. You need it because as const checks nothing at all:

1type Settings = { theme: "light" | "dark"; fontSize: number };2 3const fixed = { theme: "dark", fontSzie: 16 } as const;4const checked = { theme: "dark", fontSzie: 16 } satisfies Settings;

Line 1 says a Settings has a theme and a fontSize. Line 3 misspells the font size as fontSzie, and as const keeps the typo exactly, with no error, because nothing compares the object with Settings. Line 4 writes the same object with satisfies Settings after it. TypeScript checks it and marks line 4, on purpose: Object literal may only specify known properties, but 'fontSzie' does not exist in type 'Settings'. Did you mean to write 'fontSize'? means "Settings has no property with this name; you probably meant fontSize".

Where as const can go

Literal types put as const after a whole object and after a whole list. It can also go after one value inside an object, and an annotation is another way to get line 8 working. Press each button and watch the query on line 7:

1type Theme = "light" | "dark";2function setTheme(theme: Theme) {3  console.log(`Theme: ${theme}`);4}5 6const settings = { theme: "dark", fontSize: 16 };7//    ^?8setTheme(settings.theme);

Plain object widens theme to string, and line 8 gets the error. as const on the object keeps both values exact and makes both read-only. as const on theme only keeps just "dark" exact; fontSize stays a number and can change. A written type checks "dark" against Theme and keeps Theme, so later code could switch to "light". Every version prints Theme: dark: only the types differ.

as const only goes right after a value you write out in full: a string, a number, a boolean, a list, or an object. It can't go after a name or a call:

1const settings = { theme: "dark" };2const theme = settings.theme as const;

Line 1 makes a plain object, so settings.theme is already a string. Line 2 tries settings.theme as const, and TypeScript says A 'const' assertions can only be applied to references to enum members, or string, number, boolean, array, or object literals. In plain words: "put as const where the value is written, not after a name". A literal is a value written out in the code, like "dark" or { theme: "dark" }. By line 2 the exact value is already lost, so the fix belongs on line 1.

Read-only, all the way down

as const makes every property read-only, and it reaches inside: nested objects and lists become read-only too. Here is a shop's details, with three changes TypeScript marks on purpose:

1const shop = {2  name: "Tea House",3  hours: { open: 9, close: 17 },4  tags: ["tea", "cake"],5} as const;6 7shop.name = "Cake House";8shop.hours.open = 8;9shop.tags.push("coffee");10console.log(shop.hours.open, shop.tags.length);

• Line 7 changes the name: Cannot assign to 'name' because it is a read-only property.
• Line 8 changes a property inside hours, an object inside the shop, and gets the same message for open.
• Line 9 adds a tag: Property 'push' does not exist on type 'readonly ["tea", "cake"]'. as const turned the list into a read-only tuple: exactly these items, in this order (the Arrays & tuples lesson covers tuples). A read-only list has no methods that change it, so there's no push.

Now press Edit & run. Line 10 prints 8 3: the opening hour really changed to 8, and the list really has three tags. Like every type, as const is removed before the code runs, so nothing is left to stop the changes.

JavaScript has its own way to stop changes while the code runs: Object.freeze (the Freezing and sealing lesson covers it). It works one level deep:

1const shop = Object.freeze({ name: "Tea House", hours: { open: 9 } });2//    ^?3shop.hours.open = 8;4console.log(shop.hours.open);

Line 1 freezes the shop. The query on line 2 shows Readonly<…> around the shop's type, which means its top-level properties are read-only (Partial, Pick, Omit & friends covers Readonly later). The top-level name even stays exactly "Tea House", because it can't change. But hours inside is an ordinary { open: number; }. So line 3 gets no error, and line 4 prints 8: the nested object wasn't frozen.

The table puts the two side by side. Read each row as a question, then each tool's answer.

Read-only lists reach functions too. A parameter with a plain list type, like Size[], lets the function change the list it gets, with push for example. So TypeScript won't pass it a read-only list:

1type Size = "small" | "medium" | "large";2function countSizes(sizes: Size[]) {3  return sizes.length;4}5function countReadonly(sizes: readonly Size[]) {6  return sizes.length;7}8 9const sizes = ["small", "large"] as const;10//    ^?11console.log(countReadonly(sizes));12console.log(countSizes(sizes));13console.log(countSizes(["small", "large"]));

Line 1 lists the sizes. Lines 2 to 4 make countSizes, which takes a Size[]. Lines 5 to 7 make countReadonly, which takes a readonly Size[]: a list the function promises not to change. Line 9 makes the sizes with as const, and the query on line 10 shows readonly ["small", "large"]. Then:

• Line 11 passes the sizes to countReadonly. No error, and it prints 2.
• Line 12 passes them to countSizes, and TypeScript marks it, on purpose. The second line of the message says why: The type 'readonly ["small", "large"]' is 'readonly' and cannot be assigned to the mutable type 'Size[]'. "Mutable" means "can be changed". When it runs, it still prints 2.
• Line 13 writes the list right in the call. It needs no as const: the parameter's type, Size[], already tells TypeScript to keep "small" and "large" exact. It prints 2.

Without as const on line 9, sizes would be a string[], and neither function would take it, because any text isn't a Size. So for a fixed list you pass around, write as const, and give the functions that only read it a readonly parameter.

satisfies: check a value, keep its detail

as const keeps values exact, but it checks nothing. To check settings against a type, you could write an annotation. Here the font size may be a number or the word "auto":

1type Settings = { theme: "light" | "dark"; fontSize: number | "auto" };2 3const settings: Settings = { theme: "dark", fontSize: 16 };4//    ^?5console.log(settings.fontSize.toFixed(1));

Line 1 says a Settings has a theme and a font size that is a number or "auto". Line 3 annotates settings with it. The query on line 4 shows const settings: Settings: the annotation replaced the type. So on line 5, TypeScript has forgotten that the font size is 16. It might be "auto", and text has no toFixed, so it says Property 'toFixed' does not exist on type 'number | "auto"'.

satisfies does the check without replacing the type. You write it after the value: value satisfies Type.

1type Settings = { theme: "light" | "dark"; fontSize: number | "auto" };2 3const settings = { theme: "dark", fontSize: 16 } satisfies Settings;4//    ^?5console.log(settings.fontSize.toFixed(1));

Line 3 ends with satisfies Settings. TypeScript checks the object against Settings, then keeps the type it worked out. The query on line 4 shows theme: "dark" and fontSize: number. The theme stays exact because Settings lists exact themes. Line 5 has no error and prints 16.0.

The check is real. Type a theme and watch the list under the code:

1type Settings = { theme: "light" | "dark"; fontSize: number };2 3const settings = { theme: "blue", fontSize: 16 } satisfies Settings;4//    ^?5console.log(settings.theme);

"blue" isn't one of the two themes, so satisfies reports it. "dark" and "light" pass, and the query on line 4 shows the exact one you typed. "Dark" fails too, and TypeScript asks whether you meant "dark". Leave out the quotes, and dark becomes a name that doesn't exist.

Keeping the exact type has one cost. The variable keeps theme: "dark", not Theme, so it can't switch themes later:

1type Settings = { theme: "light" | "dark"; fontSize: number };2 3const settings = { theme: "dark", fontSize: 16 } satisfies Settings;4settings.theme = "light";

Line 3 checks the settings with satisfies. Line 4 switches to "light", which Settings allows, but TypeScript says Type '"light"' is not assignable to type '"dark"'. The variable's type is what it held, not what Settings allows. For a value that changes later, an annotation is the better fit.

The table compares the three tools. Read each row as a question, then how an annotation, as const, and satisfies answer it for the settings.

Config objects with satisfies

Apps keep a lot of fixed data in config objects: the pages of a site, the colors of a theme, the options in a menu. You want two things from TypeScript. First, a check that every entry is complete and spelled right. Second, the exact values, so your editor shows which path each page has. as const satisfies does both: as const keeps the values exact, then satisfies checks the result.

1type Route = { path: string; title: string };2type Routes = { home: Route; cart: Route; checkout: Route };3 4const routes = {5  home: { path: "/", title: "Home" },6  cart: { path: "/cart", title: "Your cart" },7  checkout: { path: "/checkout", title: "Checkout" },8} as const satisfies Routes;9 10console.log(routes.cart.path);11//                      ^?

Lines 1 and 2 describe a shop's three pages: each Route has a path and a title. Lines 4 to 8 list them, and line 8 ends with as const satisfies Routes. With Every page, the query on line 11 shows path: "/cart". Without as const, the check still passes, but the path widens to string. A misspelled page and A title left out each get an error on the line that changed. Every version prints /cart. The order matters: as const must come right after the object, so satisfies Routes as const is error 1355.

A page left out is caught too:

1type Route = { path: string; title: string };2type Routes = { home: Route; cart: Route; checkout: Route };3 4const routes = {5  home: { path: "/", title: "Home" },6  cart: { path: "/cart", title: "Your cart" },7} as const satisfies Routes;

Lines 4 to 7 list only home and cart. TypeScript marks line 7 with a long message that ends does not satisfy the expected type 'Routes', and the next line of the message says what's wrong: Property 'checkout' is missing.

Common mix-ups

• "as const freezes my object." No. It only changes what TypeScript allows. The shop's opening hour still changed to 8 when the code ran. Use Object.freeze to stop changes while the code runs.
• "as const only affects the top level." No. It reaches nested objects and lists too. That's Object.freeze, which stops at one level.
• "An as const list fits any list parameter." No. It's read-only, so it only fits a parameter that promises not to change it, like readonly Size[].
• "as const works on any value." No. It goes right after a value written out in full. After a name or a call, it's error 1355.
• "satisfies gives the variable the type I wrote." No. It checks against that type, then keeps the type TypeScript worked out. An annotation gives the variable your type.
• "satisfies is just another way to write as." No. as trusts you and checks almost nothing. satisfies checks the value fully, missing and extra properties included.
• "satisfies is always better than an annotation." No. A value checked with satisfies keeps its exact type, so it can't switch from "dark" to "light" later. For values that change, use an annotation.

Practice exercises

Each exercise is TypeScript. Press Edit & run on the starter code to try a fix: the errors and the // ^? answers update as you type, and the console shows what it prints.

1const shop = { name: "Tea House", hours: { open: 9, close: 17 } } as const;2const open = shop.hours.open;

1const shop = { name: "Tea House", hours: { open: 9, close: 17 } } as const;2const open = shop.hours.open;3//    ^?

const theme = { mode: "dark", fontSize: 16 } as const;
console.log(theme.mode);
theme.fontSize = 18;

1const theme = { mode: "dark", fontSize: 16 };2console.log(theme.mode);3theme.fontSize = 18;

1type Size = "small" | "medium" | "large";2function listSizes(sizes: Size[]) {3  console.log(sizes.join(", "));4}5 6const menuSizes = ["small", "large"] as const;7listSizes(menuSizes);

1type Size = "small" | "medium" | "large";2function listSizes(sizes: readonly Size[]) {3  console.log(sizes.join(", "));4}5 6const menuSizes = ["small", "large"] as const;7listSizes(menuSizes);

1type Settings = { theme: "light" | "dark"; fontSize: number };2 3const settings = { theme: "dark", fontSzie: 16 };4console.log(JSON.stringify(settings));

1type Settings = { theme: "light" | "dark"; fontSize: number };2 3const settings = { theme: "dark", fontSize: 16 } satisfies Settings;4console.log(JSON.stringify(settings));

1type Badge = { label: string; color: string | null };2 3const saleBadge: Badge = { label: "Sale", color: "red" };4console.log(saleBadge.color.toUpperCase());

1type Badge = { label: string; color: string | null };2 3const saleBadge = { label: "Sale", color: "red" } satisfies Badge;4console.log(saleBadge.color.toUpperCase());

1type Route = { path: string; title: string };2type Routes = { home: Route; cart: Route };3 4const routes = {5  home: { path: "/", title: "Home" },6  cart: { path: "/cart", title: "Your cart" },7} satisfies Routes;8 9const cartPath = routes.cart.path;

1type Route = { path: string; title: string };2type Routes = { home: Route; cart: Route };3 4const routes = {5  home: { path: "/", title: "Home" },6  cart: { path: "/cart", title: "Your cart" },7} as const satisfies Routes;8 9const cartPath = routes.cart.path;10//    ^?

Check your understanding

For each question, ask what each tool does: as const keeps values exact and read-only, satisfies checks without replacing the type, and neither does anything when the code runs. The quiz shows its code without the checker, so the error list doesn't give the answers away.

Key takeaways

• as const stops widening, as in Literal types. It goes right after a value written out in full, the whole object or one part of it, never after a name or a call.
• It makes every level read-only: nested objects, and lists, which become read-only tuples.
• A read-only list only fits a readonly parameter, like readonly Size[]. A list written in the call needs no as const.
• as const is removed before the code runs, so it never stops a change. Object.freeze does, one level deep.
• satisfies Type checks a value, missing, wrong, and extra properties included, then keeps the type TypeScript worked out.
• An annotation replaces the type with yours. Use it for values that change later.
• For config objects, as const satisfies Type gives you both: a full check and exact values.

Coming next: Structural typing. It starts a new stage on objects: TypeScript compares the shapes of objects, not their names, and any object with the right properties fits.