TS2769: No overload matches this call

The exact error string

function toArray(x: string): string[];
function toArray(x: number): number[];
function toArray<T>(x: T): T[] {
  return [x];
}

const value: string | number = getValue();
toArray(value);
// error TS2769: No overload matches this call.
//   Overload 1 of 2, '(x: string): string[]', gave the following error.
//     Argument of type 'string | number' is not assignable to parameter of type 'string'.
//   Overload 2 of 2, '(x: number): number[]', gave the following error.
//     Argument of type 'string | number' is not assignable to parameter of type 'number'.

An overloaded function has more than one call signature. When you call it, TypeScript tries each signature in order and, if none accepts your exact arguments, reports TS2769 and prints why each one was rejected. The error looks intimidating because it dumps every failed overload — but the trick is to ignore most of it and read only the overload you actually intended to call. Note that the implementation signature above is generic (<T>) even though the two public overloads only allow string or number — that's normal, not a mistake: the overload signatures are the restricted public API callers see, while the implementation signature can be broader internally. Callers never see or call the implementation signature directly, so it doesn't loosen what's actually allowed at a call site.

How overload resolution works (and how to read the error)

Fix 1: narrow a union argument before the call

In the example above, value is string | number. Overload 1 wants a string, overload 2 wants a number, and neither accepts the whole union — so the call fails even though every runtime value would be valid for some overload. Narrow it first:

if (typeof value === "string") {
  toArray(value);   // ✅ value is string here — overload 1 matches
} else {
  toArray(value);   // ✅ value is number here — overload 2 matches
}

Inside each branch the argument is a single concrete type, so exactly one overload applies and TS2769 disappears.

Fix 2: fix a wrong argument type

Often the mismatch is simpler — a value that's just the wrong type for the overload you wanted. This is the multi-overload cousin of TS2345. Read the sub-error for your intended overload and correct that argument:

// a real-world shape: an overloaded API client
declare function request(url: string, opts?: { method: "GET" }): Promise<Response>;
declare function request(url: string, opts: { method: "POST"; body: string }): Promise<Response>;

request("/api", { method: "POST", body: { id: 1 } });
// ❌ TS2769 — the POST overload wants body: string, you passed an object
request("/api", { method: "POST", body: JSON.stringify({ id: 1 }) });
// ✅ body is now a string — the POST overload matches

Passing raw objects where a serialized string is expected is a classic trigger here; when the target type is a string body, run the value through JSON stringify (or JSON.stringify) first.

Fix 3: an options object with a wrong or extra property

When overloads differ by the shape of an options object, a single bad property rejects every overload. The last overload's sub-error usually points right at it:

// ❌ 'responseType' has a typo'd value; no overload accepts "jsonn"
axiosLike.get("/users", { responseType: "jsonn" });
//   ... Type '"jsonn"' is not assignable to type 'ResponseType'.

// ✅ correct the property value
axiosLike.get("/users", { responseType: "json" });

Excess-property checks make object literals especially strict here: an extra property that no overload declares is itself enough to cause TS2769, so also check for a stray or misnamed key, not just a wrong value.

Fix 4: wrong number of arguments

If your argument count matches no overload — too few required arguments, or more than any signature accepts — you get TS2769 as well. Compare your call against each signature's arity and pass the set of arguments one real overload declares.

Fix 5: a literal type got widened before the call

This one is confusing because, unlike Fix 1, there's no visible union anywhere in your code — the value just looks like it should match. The culprit is TypeScript's literal-widening rule: assigning a string literal to a let widens its type to the general string, discarding the specific literal:

function setStatus(status: "active"): void;
function setStatus(status: "inactive"): void;

let status = "active";      // widened to `string`, not the literal "active"
setStatus(status);          // TS2769 — no overload accepts a plain string

Both overloads only accept a specific string literal, but status's inferred type is the wider string, and string isn't assignable to either literal type — so neither overload matches, even though the runtime value "active" is exactly what one overload wants. Fix it by preventing the widening, not by changing the value:

let status = "active" as const;              // ✅ keeps the literal type "active"
// or:
let status: "active" | "inactive" = "active"; // ✅ explicit union annotation
// or, if the value never needs to be reassigned:
const status = "active";                      // ✅ const infers the literal type directly

Diagnose this by checking the declaration, not the call: if the argument is declared with let and no type annotation, and every overload expects a specific literal, widening is very likely the cause.

Fix 6: the library's overloads changed after an upgrade

Sometimes none of the above applies because the code used to compile and nothing in your call site changed — only a dependency version did. A minor or major upgrade of a library can add, remove, or reshape its overload signatures, and existing calls that matched the old signatures stop matching the new ones. When TS2769 appears right after running npm update or bumping a version in package.json:

• Check the installed version of the package against the version your code was written for — a changelog or migration guide often documents the overload change directly.
• If you're unsure what changed, diff the relevant .d.ts file between the two versions in node_modules (or on a site like unpkg) to see the exact signature difference.
• Update the call site to match the new signature — this is usually a small, mechanical change once you know what moved, rather than a sign your code was ever wrong.

Common React TS2769 cases

Two patterns produce a genuine TS2769 in React code specifically — both are argument-count or overload-selection failures, the same class of problem as Fix 4:

// too many arguments — same class as Fix 4
const [count, setCount] = useState(0, 10);
// TS2769: Expected 0-1 arguments, but got 2.

// no overload of useRef accepts this initial value's type
const ref = useRef<HTMLInputElement>("not a DOM node");
// TS2769: No overload matches this call.

useState only ever takes zero or one argument (the initial state); a second argument matches no overload, exactly like Fix 4. useRef<HTMLInputElement> is overloaded on the initial value's type, and a string doesn't satisfy any of them. Two other React errors get miscategorized as this one but aren't — worth knowing so you land on the right fix: passing the wrong value to a single-signature setter like useState(null) then setValue("hello") is TS2345, not TS2769 (there's only one signature, not several); and a bad JSX prop like <MyButton size="largee" /> is TS2322, since JSX props are checked as object-literal assignability, not function overload resolution.

What NOT to do

Casting the argument to any (toArray(value as any)) forces an overload to accept it and makes the red squiggle vanish — but it also turns off checking for that argument, so a genuinely wrong call sails through to runtime. Narrow the union, fix the type, or correct the argument count instead. Reach for a cast only when you've confirmed at runtime that the value really is valid for the overload you're calling.

Debugging checklist

• ✓ Identify which overload you meant to call, and read only that sub-error
• ✓ The sub-error names one argument and the type it expected — fix that argument
• ✓ Union argument (string | number)? Narrow with typeof / a type guard first
• ✓ Options object? Look for a wrong value or an extra/misnamed property
• ✓ Count mismatch? Match your argument count to a real signature's arity
• ✓ Value declared with let, overloads expect a specific literal? Check for widening — use as const or an explicit union type
• ✓ Started right after a dependency upgrade? Diff the library's .d.ts for a changed overload
• ✓ Don't cast to any to silence it — that ships the real bug to runtime