In TypeScript generics, what does each of the constraints `T extends object`, `T extends {}` and `T extends unknown` actually allow a caller to pass?

## Three constraints, three different sets Candidates routinely rank these as "loose, looser, loosest" and get the order wrong, because two of the three names suggest something other than what they mean. ### `T extends object` — non-primitive `object` is the type of everything that is *not* a primitive. Primitives are `string`, `number`, `bigint`, `boolean`, `symbol`, `null` and `undefined`; everything else — arrays, tuples, functions, class instances, plain object literals — is assignable. ```ts declare function f<T extends object>(x: T): T; f([1, 2]); // ok f(() => {}); // ok f(new Date()); // ok // f("hi"); // Error TS2345: Argument of type 'string' is not assignable to parameter of type 'object'. ``` Use it when the body does something only reference values support — spreading, `Object.keys`, storing in a `WeakMap`. ### `T extends {}` — anything but `null` and `undefined` The empty object type is not "an object with no properties". Assignability asks *does the source have everything the target requires*, and `{}` requires nothing, so almost every type qualifies — including primitives, which are assignable because they have the members of their wrapper types. ```ts declare function g<T extends {}>(x: T): T; g(42); // ok g("hi"); // ok g([1, 2]); // ok // g(null); // Error TS2345: Argument of type 'null' is not assignable to parameter of type '{}'. ``` The only values it excludes are `null` and `undefined`, which have no members at all. That is the whole basis of the standard library definition `type NonNullable<T> = T & {}` — intersecting with `{}` strips the null-ish members of a union. ### `T extends unknown` — no constraint at all `unknown` is the top type: every type is assignable to it. As a constraint it filters nothing, so `<T extends unknown>` accepts exactly the same arguments as a bare `<T>`, `null` and `undefined` included. It has one practical use: in a `.tsx` file a generic arrow function `<T>(x: T) => x` is parsed as a JSX element, and writing `<T extends unknown>(x: T) => x` (or the trailing-comma form `<T,>`) disambiguates it. Inside the body it buys nothing — an unconstrained parameter is already treated as `unknown`, so you still cannot read any member off it. ## The ordering, stated once From most to least restrictive: `object` (no primitives) → `{}` (no null-ish) → `unknown` (nothing excluded). The intuitive ranking that puts `{}` tightest is the classic wrong answer. ## `strictNullChecks` changes the picture With `strictNullChecks` off, `null` and `undefined` are assignable to every type, so `T extends {}` stops rejecting them and becomes indistinguishable from `T extends unknown`. Any interview answer about `{}` should state the assumption; in a modern codebase `strict` is on and the distinction is real. ## Choosing between them The honest default is **none of the three**. A constraint should describe the members the body actually uses, so `T extends { id: string }` beats `T extends object` whenever you read `id`. The three broad constraints are for the cases where you genuinely accept anything of a category: - Reach for `object` when the operation is meaningless on primitives — a deep-merge helper, a `WeakMap` cache key, a proxy wrapper. - Reach for `{}` when the only thing you must exclude is null-ness — a helper that asserts presence, or the shape mirrored by `NonNullable`. - Reach for `unknown` only for the `.tsx` parsing workaround, and be explicit that it is a syntax fix, not a type decision. ## Related traps Two further points come up in follow-ups. First, `object` is not the same as `Object`: the capitalised interface is the type of `Object.prototype`'s members, and primitives *are* assignable to it, which makes it a poor constraint. Second, none of this survives compilation — all three constraints are erased, so a value arriving through `any` can be `null` at runtime no matter which one you wrote.