The TypeScript satisfies Operator, Explained

The satisfies operator tells TypeScript to check that a value matches a given type, without changing the type TypeScript infers for that value. It closes a long-standing gap between two bad options: annotate a variable with a type and lose precise inference, or skip the annotation and lose the safety check. satisfies gets you both.

The problem: annotations widen, inference alone doesn’t check

Say you’re defining a config object where the values should each be a valid CSS color:

type Palette = Record<string, string>;

const colors: Palette = {
  primary: "#3b82f6",
  secondary: "#8b5cf6",
};

Annotating colors: Palette checks that every value is a string, but it also widens the type of colors to Palette — that is, Record<string, string>. TypeScript forgets that colors.primary was specifically "#3b82f6" and that the object only has primary and secondary keys. Autocomplete on colors. now suggests nothing useful, because as far as the type system is concerned, colors could have any string keys.

Drop the annotation entirely and TypeScript infers the precise literal shape — but now nothing checks that each value is actually a valid color. A typo like "#3b82fg" (not a real hex code) would pass silently, since without the annotation TypeScript just sees string.

What satisfies does differently

satisfies validates the expression against a type and then discards the check — the variable keeps whatever type TypeScript would have inferred without the annotation:

type Palette = Record<string, string>;

const colors = {
  primary: "#3b82f6",
  secondary: "#8b5cf6",
} satisfies Palette;

colors.primary; // type is "#3b82f6", not string
colors.tertiary; // error: property doesn't exist

TypeScript still verifies every value conforms to Palette (all strings), but colors itself keeps its narrow, literal-typed shape. You get validation and precise inference in the same declaration — something neither a type annotation nor bare inference could do alone.

A more concrete example: exhaustive route configs

satisfies shines with object literals that need to satisfy a shape while keeping their specific keys accessible elsewhere in the code:

type RouteConfig = {
  path: string;
  auth: boolean;
};

const routes = {
  home: { path: "/", auth: false },
  dashboard: { path: "/dashboard", auth: true },
} satisfies Record<string, RouteConfig>;

// routes.home and routes.dashboard are both known keys
type RouteName = keyof typeof routes; // "home" | "dashboard"

Without satisfies, annotating routes: Record<string, RouteConfig> directly would make keyof typeof routes resolve to string, not the specific route names — losing exactly the information RouteName needs.

satisfies vs. a type annotation vs. as

	: Type annotation	as Type assertion	satisfies Type
Checks the value against the type	Yes	No (bypasses checking)	Yes
Preserves literal/narrow inferred type	No — widens to the annotated type	Yes, but unsafely	Yes, safely
Can silence real type errors	No	Yes — this is the risk	No
Typical use	You want the variable typed broadly	Rare — telling TypeScript “trust me”	You want validation and narrow inference together

as is worth calling out specifically because it looks similar but does the opposite of what you usually want: it forces a type onto a value without checking anything, which is how mismatched assertions slip past the compiler. satisfies checks first and only then lets you keep the inferred type — there’s no unsafe override involved.

When not to bother

If you genuinely want the wider type — say, a function parameter typed as Palette so callers can pass any object shaped like one — a plain annotation is still the right tool. satisfies is specifically for the case where you want validation on the definition site while preserving specificity for consumers of that value. It’s most useful for generics-adjacent code, configuration objects, and anywhere you’d otherwise reach for a utility type like Record or Pick just to check shape, at the cost of losing the literal keys you actually wanted to keep.

It also isn’t a replacement for runtime validation. satisfies is a compile-time check against your declared types — it says nothing about data coming from an API response or user input at runtime, which is a job for a schema validator, not the type system alone.

The takeaway

satisfies fills the gap between “annotate and lose precision” and “infer and lose validation.” It checks a value against a type at the point you write it, then hands back the same narrow type TypeScript would have inferred anyway — no widening, no unsafe override. Reach for it whenever you need a literal object to be checked against a shape while still being usable by its specific keys and values elsewhere in your code.