Your TypeScript config objects are losing type information. satisfies fixes it.

There is a config.ts in most TypeScript projects that looks something like this:

The annotation validates the object. Miss a key, TypeScript tells you. Use a non-string value, TypeScript tells you. That's the whole point of the annotation. Now look at what you get when you use it:

TypeScript knows the value is a string. It doesn't know it's 'Waiting'. The moment you wrote : Record<Status, string>, TypeScript swapped the inferred type for the declared type and threw away the actual values. You validated the shape, but you gave up precision to do it.

For STATUS_LABELS, that trade is usually fine. But pick a more demanding example — a component icon registry:

You've lost the specific component types. TrashIcon might have a size prop; TypeScript no longer knows. Any access through ICONS returns the widened union. The annotation bought validation and cost you everything the concrete types were worth.

satisfies arrived in TypeScript 4.9 (November 2022). The syntax is expression satisfies Type. It checks that the left side is compatible with the type on the right — the same check as an annotation — but the resulting inferred type stays as the expression's own type, not the annotation's.

TypeScript validates that each value is a React.ComponentType. If you put a string in there by mistake, you get an error. But the inferred type of ICONS.trash stays as typeof TrashIcon. The check happened; the widening didn't.

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

Route maps. A central route object is a common pattern, and getting its keys as a typed union is useful for navigation functions:

The annotation validated the paths are strings. satisfies did the same validation and also kept the named keys as a union — so every call to navigate() is checked against the actual routes in your config.

Exhaustive pattern validation. When you have a discriminated union and want to map every case to something:

Add a new shape kind to the union and TypeScript immediately tells you AREA_FORMULAS is no longer exhaustive — without you having to look it up.

as is a type assertion: you are telling TypeScript what the type is, skipping its inference. It's useful when TypeScript can't see something you can — reading from the DOM, narrowing after an external type guard — but it provides no validation.

satisfies is the opposite: TypeScript checks, then steps back. Use as when the compiler lacks information and you have it. Use satisfies when you have information and want the compiler to verify it without losing it. Use : Type annotation when you want to commit to the wider type throughout the file and don't need the narrow inference.

Two things to notice. First, satisfies keeps the exact keys either way — keyof typeof routes is the real union, so key access and Object.keys stay precise. Second, the value literal '/' only survives because the target's value type (Path) is itself a literal union; against a wider target like Record<string, string> the values would still widen to string. Add a value outside Path to either declaration and TypeScript catches it. The only difference is what comes out the other side.

Think it clicked? Take the 6-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

Use satisfies for any const you define inline and then access by its specific keys or values — config maps, icon registries, route definitions, theme tokens, anything where the precise shape matters downstream. Use annotation when you want to commit to the wider type and everything accessing it should see only that wider type. Use as when TypeScript can't see the correct type on its own.

You've been choosing between safety and precision. satisfies was added so you don't have to.

Thanks for reading! Let's stay connected: