No overload matches this call is one of TypeScript's most notoriously unhelpful-looking error messages at first glance — it doesn't tell you what's wrong directly, it tells you that none of a function's multiple declared signatures fit your call, and the actually useful information is buried in a list of sub-errors for each overload that TypeScript prints below the main message.
This error means you're calling a function that has multiple declared overload signatures (common in libraries like the DOM API, Express, or complex utility libraries), and your specific combination of arguments doesn't match any of them — the fix requires understanding which overload you intended to match and why your arguments don't satisfy it.
Why This Error Happens
Overloaded functions declare several valid call signatures, each with different parameter types or counts, letting the same function name support meaningfully different usage patterns (like document.createElement("div") returning a specifically-typed HTMLDivElement versus a generic string returning HTMLElement). When your call doesn't match any declared signature — wrong argument type, wrong count, or an argument order that fits no overload — TypeScript reports this generic top-level error, along with (usually below it, sometimes requiring scrolling in your editor's error panel) more specific reasons each individual overload failed to match.
Reproducing the Error
A call missing a required argument for the intended overload:
function createElement(tag: "input", props: { type: string; value: string }): HTMLInputElement;
function createElement(tag: "div", props: { className: string }): HTMLDivElement;
function createElement(tag: string, props: Record<string, unknown>): HTMLElement {
// implementation
return document.createElement(tag) as HTMLElement;
}
createElement("input", { type: "text" });
// Error: No overload matches this call.
// Overload 1 of 2, '(tag: "input", props: { type: string; value: string }): HTMLInputElement',
// gave the following error. Property 'value' is missing in type '{ type: string; }'
// but required in type '{ type: string; value: string; }'.
The sub-error (often the most useful part) directly identifies the missing value property for the first overload — this is the actual fix, even though the top-level message alone doesn't say it.
Core Concepts Behind This Error
The sub-errors listed for each individual overload are the actually diagnostic content, and editors/terminals sometimes truncate or collapse them by default — expanding the full error output (hovering longer in VS Code, or checking the full tsc output rather than a truncated editor tooltip) is often necessary to see the specific reason each overload failed.
TypeScript checks overloads in declaration order and reports on the first reasonably-close match's failure reasons, not necessarily every overload equally — this means the sub-error shown might correspond to an overload you didn't even intend to match, which can be confusing if you assumed it was evaluating against the overload you meant to use.
Overload resolution failures are often actually simpler type mismatches wearing a more intimidating error message — a wrong argument type, a missing property, or an extra unexpected argument are the same categories of error you'd see for a non-overloaded function, just reported through the more complex overload-matching mechanism.
Generic type parameters interacting with overloads can produce especially confusing versions of this error, where the actual mismatch is in how a generic type argument was inferred rather than an obvious literal type mismatch — these cases sometimes benefit from explicitly specifying the generic type argument to get a clearer, more specific error.
Fixing "No Overload Matches This Call"
Fix 1: Read the sub-errors carefully to identify the specific overload you intended and exactly what's mismatched, then fix that specific mismatch:
createElement("input", { type: "text", value: "" }); // added the missing required property
Fix 2: If the intended overload is ambiguous from the error alone, check the function's type definition directly (via "Go to Definition" in your editor) to see all declared overloads and compare your call against each explicitly:
// Viewing the actual overload signatures clarifies which one your call should match
function createElement(tag: "input", props: { type: string; value: string }): HTMLInputElement;
function createElement(tag: "div", props: { className: string }): HTMLDivElement;
Fix 3: For generic-related overload confusion, explicitly specify the type argument to get a more direct, specific error message rather than relying on inference through the overload resolution:
// Instead of letting inference struggle across overloads:
someGenericOverloadedFunction(value);
// Explicit type argument often produces a clearer error or resolves the ambiguity:
someGenericOverloadedFunction<SpecificType>(value);
Why Doesn't TypeScript Just Tell You Directly Which Argument Is Wrong?
Because with multiple overloads, there isn't a single "correct" signature TypeScript can assume you meant — your call might be attempting to match any of several signatures, and TypeScript reports the failure reasons for each candidate rather than guessing your intent. This is genuinely more complex to report clearly than a single-signature function's type mismatch, which is part of why the top-level message stays generic while the real information lives in the per-overload sub-errors.
Preventing This Error in Production
When working with heavily-overloaded APIs (DOM APIs, complex library functions), check "Go to Definition" to see all available overload signatures before writing a call, rather than guessing and iterating against error messages. When designing your own overloaded functions, keep signatures as distinguishable as possible (clearly different argument counts or clearly different literal types for the first parameter) to make overload resolution failures easier for callers to diagnose from the error output alone.
If you hit this error, expand the full error output to read every sub-error rather than stopping at the generic top-level message — the actual fix is almost always specified clearly in one of those per-overload explanations.