typescriptseverity: can-fix
TS2769

TypeScript TS2769: No overload matches this call

No overload matches this call

92% fixable~8 mindifficulty: intermediate

Verified against TypeScript docs: Function Overloads, TypeScript handbook: More on Functions, TypeScript 5.5 release notes · Updated June 2026

> quick_fix

TypeScript tried every overload of the function and none accepted your arguments. The error lists each overload and why it failed. Read the 'Overload X of Y' messages to find which overload you intended, then fix the argument that doesn't match. Usually it's a wrong type, missing argument, or extra argument.

// TS2769: No overload matches this call.
// Overload 1: createElement(type: string, props: ...)
// Overload 2: createElement(type: ComponentType, props: ...)
React.createElement(MyComponent, { unknownProp: true })

// Fix: pass props that match the component's prop type
React.createElement(MyComponent, { name: 'Alice' })

What causes this error

TS2769 fires when a function has multiple overload signatures and the arguments you pass don't match any of them. TypeScript tries each overload in declaration order and collects the failure reasons. When none succeed, it reports TS2769 with the failure details for each overload. This commonly occurs with DOM APIs (addEventListener, createElement), React APIs (useState, useRef), and library functions with complex overloads.

> advertisementAdSense placeholder

How to fix it

  1. 01

    step 1

    Read all overload failure messages

    TS2769 includes a sub-error for each overload that failed. Each sub-error explains why that specific overload didn't match. Find the overload you intended to use and read its specific failure reason — that's the argument you need to fix.

    No overload matches this call.
      Overload 1 of 2, '(event: "click", handler: (e: MouseEvent) => void): void',
        gave the following error:
          Argument of type '"hover"' is not assignable to parameter of type '"click"'.
      Overload 2 of 2, '(event: "keydown", handler: (e: KeyboardEvent) => void): void',
        gave the following error:
          Argument of type '"hover"' is not assignable to parameter of type '"keydown"'.
  2. 02

    step 2

    Fix the argument type that fails across all overloads

    Often one argument is wrong for all overloads. Fix that argument and the error resolves. Common cases: passing a string literal that doesn't match any accepted union member, or passing an object with wrong property types.

    // addEventListener has overloads for specific event names
    const el = document.getElementById('btn')!
    
    // TS2769: 'clck' doesn't match any overload
    el.addEventListener('clck', (e) => {})  // typo
    
    // Fix: correct event name
    el.addEventListener('click', (e) => {})  // OK
  3. 03

    step 3

    Check argument count and order

    Different overloads may expect different numbers of arguments. If you're passing too many or too few, no overload will match. Check the function's type signature to see what each overload expects.

    // useState has two overloads:
    // useState<T>(initialState: T): [T, Dispatch<SetStateAction<T>>]
    // useState<T>(): [T | undefined, Dispatch<SetStateAction<T | undefined>>]
    
    // TS2769 when argument type is ambiguous
    const [val, setVal] = useState(null)  // null matches no specific overload cleanly
    
    // Fix: provide the type parameter
    const [val, setVal] = useState<string | null>(null)  // OK
  4. 04

    step 4

    Handle React component prop mismatches

    In React with TypeScript, JSX elements are type-checked against component prop types. Passing props that don't match any overload of createElement (which JSX compiles to) triggers TS2769. The fix is to correct the props.

    interface ButtonProps {
      variant: 'primary' | 'secondary'
      onClick: () => void
    }
    
    function Button({ variant, onClick }: ButtonProps) {
      return <button className={variant} onClick={onClick}>Click</button>
    }
    
    // TS2769: 'tertiary' not assignable to 'primary' | 'secondary'
    <Button variant="tertiary" onClick={() => {}} />
    
    // Fix: use a valid variant
    <Button variant="primary" onClick={() => {}} />
  5. 05

    step 5

    Narrow types before calling overloaded functions

    When passing a union type to an overloaded function, TypeScript may not be able to match any single overload. Narrow the union first so TypeScript can pick the right overload.

    // Overloaded function
    function format(value: string): string
    function format(value: number): string
    function format(value: string | number): string {
      return String(value)
    }
    
    const input: string | number = getValue()
    
    // TS2769: union doesn't match either overload
    format(input)  // Error
    
    // Fix: narrow first
    if (typeof input === 'string') {
      format(input)  // matches overload 1
    } else {
      format(input)  // matches overload 2
    }

How to verify the fix

  • Run tsc --noEmit and confirm TS2769 no longer appears
  • Hover over the function call in VS Code to verify the correct overload is selected
  • Check that the fix doesn't introduce a different type error downstream

Why TS2769 happens at the runtime level

TS2769 is emitted by the overload resolution logic in src/compiler/checker.ts. When TypeScript encounters a call to a function with multiple overload signatures, it iterates through each overload in declaration order and attempts to match the arguments. For each overload, it runs the same assignability checks as TS2345. If no overload succeeds, the checker collects all failure diagnostics and wraps them in a TS2769 error that shows which overload failed and why. The implementation signature (the actual function body) is intentionally excluded from overload resolution — callers can only match against declared overload signatures.

Common debug mistakes for TS2769

  • Passing a union type that spans multiple overloads — narrow before calling.
  • Typos in string literal arguments that must match a specific union of event names or keys.
  • Passing null or undefined without a type annotation to useState or useRef, blocking overload inference.
  • Confusing the implementation signature with callable overloads — the implementation isn't directly callable.
  • Adding extra properties to an object argument that trigger excess property checking on all overloads.

When TS2769 signals a deeper problem

TS2769 errors that keep appearing in a codebase often signal that the overloaded API is too complex for its callers. Overload signatures are a blunt tool — they enumerate specific valid combinations, and any combination not listed fails. When a library has 10+ overloads (common in DOM APIs and some React patterns), the error messages become walls of text that are hard to parse. The deeper issue is API design: conditional types and generic constraints can often replace overloads with a single signature that's both more flexible and produces better error messages. If you control the function, consider refactoring to generics.

Editor's take

TS2769 produces the longest, most intimidating error messages in TypeScript. A single function call can generate a wall of text listing every overload signature and why each one failed. The natural reaction is to scroll past it and try random fixes until the red squiggly goes away. That's the wrong approach — the error is actually well-structured if you know how to read it.

Each 'Overload X of Y' block is an independent failure report. Find the overload that matches your intent — the one where you agree with most of the parameter types — and read only that block's failure reason. It's usually a single argument that's wrong: a string literal typo, a missing null check, or a union type that needs narrowing. Fix that one argument and the error resolves.

The most common TS2769 trigger in React is useState and useRef with null initial values. Writing useState(null) gives TypeScript no information about the intended state type, so it can't match either overload cleanly. The fix is always the same: provide the type parameter explicitly. useState<User | null>(null) tells TypeScript exactly what you want.

DOM APIs are the other major source. addEventListener has overloads for every standard event name, each mapping to the correct Event subtype. When you pass a string that doesn't match any known event name — even a valid custom event — TS2769 fires with dozens of overloads listed. For custom events, use the generic fallback: addEventListener('my-event', (e: Event) => {}).

A subtlety that trips up intermediate users: overload resolution doesn't distribute over unions. If you pass string | number to a function with separate string and number overloads, neither accepts the full union. Narrow first.

By Bikram Nath · Curator · Updated June 2026

Frequently asked questions

Why can't TypeScript match a union type to any overload?

TypeScript checks each overload signature independently against the full argument type. If the argument is string | number and overload 1 expects string and overload 2 expects number, neither overload accepts the full union. TypeScript doesn't try to split the union across overloads — it needs one overload that handles the entire argument type. The implementation signature (the one with string | number) isn't callable directly; only the overload signatures are visible to callers. Narrow the argument type first so TypeScript can match a specific overload.

How do I find the correct overload to target?

In VS Code, hover over the function name to see all overload signatures. Read each one and find the signature that matches your intent. The TS2769 error message also lists each overload with its failure reason — the overload closest to what you want (fewest sub-errors) is usually the one to target. For DOM and React APIs, the TypeScript declaration files in node_modules/typescript/lib/ and node_modules/@types/react/ list all overloads with JSDoc comments.

Can I add my own overload to fix TS2769?

You can add overloads to your own functions by declaring multiple function signatures before the implementation. For third-party libraries, you can use declaration merging or module augmentation to add overloads, but this is risky — you're telling TypeScript your addition is type-safe without the library guaranteeing it. A better approach is to wrap the library function with your own typed function that handles the specific case you need.

disclosure:Errordex runs AdSense, has zero third-party affiliate or sponsored links, and occasionally links to the editor’s own paid digital products (clearly labelled). Every fix is cross-referenced against the official sources listed in the “sources” sidebar before it ships. If a fix here didn’t work for you, please email so we can update the page.