TypeScript satisfies Operator: vs Type Annotations and as

value satisfies Type checks that value matches Type at compile time, and then leaves the value's own, more precise type alone. An annotation would replace that precise type with Type; satisfies validates without widening.

type ColorName = "red" | "green" | "blue";
type Color = string | [number, number, number];

const palette = {
  red: [255, 0, 0],
  green: "#00ff00",
  blue: [0, 0, 255],
} satisfies Record<ColorName, Color>;

// Checked against the Record, yet every property keeps its own type:
console.log(palette.green.toUpperCase());      // #00FF00 (green: string)
console.log(palette.red.map((c) => c / 255));  // [ 1, 0, 0 ] (red: [number, number, number])

satisfies still does the checking: a missing color, a misspelled key such as bleu, or a value like true is a compile error on that line. It exists since TypeScript 4.9 and, like every type annotation, it is removed from the emitted JavaScript.

The Problem satisfies Solves

With a type annotation, the variable's type is the annotation. The compiler forgets what it saw in the literal. Here the same palette is annotated instead, and now TypeScript no longer knows that green is a string:

// This does not compile: the annotation widens every property to Color.
type ColorName = "red" | "green" | "blue";
type Color = string | [number, number, number];

const palette: Record<ColorName, Color> = {
  red: [255, 0, 0],
  green: "#00ff00",
  blue: [0, 0, 255],
};

console.log(palette.green.toUpperCase());

The compiler reports:

index.ts(11,27): error TS2339: Property 'toUpperCase' does not exist on type 'Color'.
  Property 'toUpperCase' does not exist on type '[number, number, number]'.

Before TypeScript 4.9 the choices were: annotate and narrow by hand everywhere (typeof palette.green === "string"), or skip the annotation and lose the check. satisfies gives both. Change : Record<ColorName, Color> to satisfies Record<ColorName, Color> after the closing brace and it runs.

satisfies vs Type Annotation vs as

The same settings object, written three ways:

type Settings = {
  theme: "light" | "dark";
  fontSize: number;
  lang: string;
};

const annotated: Settings = { theme: "dark", fontSize: 14, lang: "en" };
const asserted = { theme: "dark", fontSize: 14 } as Settings; // lang is missing!
const satisfied = { theme: "dark", fontSize: 14, lang: "en" } satisfies Settings;

// annotated.theme: "light" | "dark"   (the annotation's type)
// satisfied.theme: "dark"             (what was actually written)
const isDark: "dark" = satisfied.theme; // fine; annotated.theme would be rejected

console.log(annotated.lang, asserted.lang, satisfied.lang); // en undefined en
console.log(isDark);                                         // dark

as let the missing lang through, and asserted.lang is undefined at run time while its type says string. Remove lang from the other two lines and both fail with TS2741, Property 'lang' is missing in type ....

Rule of thumb: annotate when you want the variable to have the declared type (a value you will reassign, a public API), and use satisfies when you want a check but the value's own type is more useful.

Catching Mistakes in Object Literals

satisfies runs the full assignability check, including excess property checks, so typos in keys are errors:

type Route = { path: string; method: "GET" | "POST" };

const home = { path: "/", metod: "GET" } satisfies Route;
// error TS2561: Object literal may only specify known properties, but 'metod' does not exist in type 'Route'. Did you mean to write 'method'?

The check also gives the literal a contextual type, just as an annotation does. That matters in two ways. String literals are kept as literal types when the target type expects them: { path: "/", method: "GET" } satisfies Route has method: "GET", while the same object with no annotation would infer method: string. And callback parameters are inferred from the target type:

type Handlers = {
  onSave: (doc: { id: number; title: string }) => string;
  onDelete: (id: number) => boolean;
};

const handlers = {
  onSave: (doc) => `saved #${doc.id}: ${doc.title}`, // doc is typed from Handlers
  onDelete: (id) => id > 0,
} satisfies Handlers;

console.log(handlers.onSave({ id: 7, title: "Notes" })); // saved #7: Notes
console.log(handlers.onDelete(-1));                      // false

Record Keys Stay Known

A common use is a lookup table. Annotated as Record<string, T>, every string is a valid key and a typo compiles, returning undefined at run time. With satisfies, the values are still checked against T, but the variable's type lists exactly the keys you wrote:

type Endpoint = { url: string; timeoutMs: number };

const loose: Record<string, Endpoint> = {
  users: { url: "/api/users", timeoutMs: 3000 },
};

const endpoints = {
  users: { url: "/api/users", timeoutMs: 3000 },
  orders: { url: "/api/orders", timeoutMs: 8000 },
} satisfies Record<string, Endpoint>;

console.log(loose.userz?.url); // undefined: the typo compiles
console.log(endpoints.orders.timeoutMs); // 8000

type EndpointName = keyof typeof endpoints; // "users" | "orders"
const endpointName: EndpointName = "users";
console.log(endpoints[endpointName].url); // /api/users

// @ts-expect-error: TS2551 Property 'userz' does not exist on type ... Did you mean 'users'?
endpoints.userz;

keyof typeof endpoints is only useful because the keys survived. With the annotation it would be plain string.

To require a fixed set of keys, satisfy a Record over a union: satisfies Record<"dev" | "prod", string> reports a missing prod with TS2741 and an unknown staging with TS2353.

as const satisfies

as const and satisfies combine. Write as const first: it makes the value deeply readonly with literal types, then satisfies checks that exact value.

type Route = { path: string; method: "GET" | "POST"; auth: boolean };

const routes = [
  { path: "/", method: "GET", auth: false },
  { path: "/login", method: "POST", auth: false },
  { path: "/account", method: "GET", auth: true },
] as const satisfies readonly Route[];

type Path = (typeof routes)[number]["path"]; // "/" | "/login" | "/account"

function link(path: Path): string {
  return `<a href="${path}">`;
}

console.log(link("/account"));                           // <a href="/account">
console.log(routes.filter((r) => r.auth).map((r) => r.path)); // [ '/account' ]

Each route is checked against Route (a method: "PUT" would be an error), and the tuple of literal types stays available, so Path is a union of the real paths. Use readonly Route[] (or ReadonlyArray<Route>) as the target, since an as const array is readonly.

Config Objects

Configuration is where satisfies earns its place: the shape must be right, and code elsewhere wants the precise values.

type Env = "development" | "production";

type AppConfig = {
  port: number;
  logLevel: "debug" | "info" | "warn";
  features: Record<string, boolean>;
};

const configs = {
  development: { port: 3000, logLevel: "debug", features: { newCheckout: true } },
  production: { port: 8080, logLevel: "warn", features: { newCheckout: false } },
} satisfies Record<Env, AppConfig>;

function start(env: Env): string {
  const c = configs[env];
  return `${env}: port ${c.port}, log ${c.logLevel}, newCheckout=${c.features.newCheckout}`;
}

console.log(start("development")); // development: port 3000, log debug, newCheckout=true
console.log(start("production"));  // production: port 8080, log warn, newCheckout=false

Forget the production entry, misspell logLevel, or write logLevel: "verbose", and the compiler points at the exact line. The same pattern suits *.config.ts files: export default { ... } satisfies SomeConfig checks the whole file while the exported object keeps its literal values.

When Not to Use satisfies

• The variable will be reassigned. let cfg = { port: 3000 } satisfies { port: number | string } gives cfg the type { port: number }, so a later cfg = { port: "80" } fails (TS2322). Annotate variables you mean to change.
• You want the declared type on purpose. For a function return value or an exported constant that is part of an API, the annotation's type is the contract, and leaking the exact literal type can make later changes breaking.
• The value is not a literal. satisfies shines on object and array literals. On a variable or a call result it is a plain assignability check, which an annotation already gives you.