Fix TS2532: Object is Possibly Undefined (2026)

TypeScript throws TS2532 when you try to use a value that could be undefined. The message reads:

Object is possibly 'undefined'. ts(2532)

This appears when strictNullChecks is on (which comes with strict: true in tsconfig.json). It is one of TypeScript’s most useful checks because it forces you to handle the case where a value might not exist. Here are five ways to fix it.

The simplest reproducer

function greet(name?: string) {
  console.log(name.toUpperCase());  // TS2532
}

The ? in the parameter makes name either a string or undefined. Calling .toUpperCase() on undefined would crash at runtime, so TypeScript blocks it at compile time.

Fix 1: Guard with an if check

The most explicit fix. It also narrows the type automatically inside the block:

function greet(name?: string) {
  if (name) {
    console.log(name.toUpperCase());  // OK, narrowed to string
  }
}

Use this when the code that follows only makes sense with a defined value. If undefined should also be handled, add an else branch.

Fix 2: Optional chaining

When you just want to access a property or method safely and get undefined if the value is missing, use the ?. operator:

function greet(name?: string) {
  console.log(name?.toUpperCase());  // OK, logs undefined if name is undefined
}

const user = getUser();
const city = user?.address?.city;  // safely walks the chain

Optional chaining short-circuits: if any part of the chain is null or undefined, the whole expression evaluates to undefined without throwing. Great for API responses where nested properties might be missing.

Fix 3: Nullish coalescing for defaults

When you want a fallback value when the original is undefined or null, use ??:

function greet(name?: string) {
  const displayName = name ?? "Guest";
  console.log(displayName.toUpperCase());  // OK, displayName is string
}

Do not use || for this. || also falls back on 0, empty string, and false, which is often a bug. ?? only falls back on null and undefined.

Fix 4: Default parameter value

If the value is a function parameter and you always want a default, set it in the signature:

function greet(name: string = "Guest") {
  console.log(name.toUpperCase());  // OK, name is always string
}

Cleaner than doing the default check inside the function body. Works for function parameters and destructured object properties.

Fix 5: The non-null assertion (use with care)

If you know the value cannot be undefined at that point but the compiler cannot prove it, use the ! operator:

function greet(name?: string) {
  // I validated name upstream and I know it is defined here
  console.log(name!.toUpperCase());
}

This turns off the check but does not add any runtime safety. If you are wrong, the code crashes at runtime with “Cannot read property ‘toUpperCase’ of undefined”. Only use this when you are truly certain and the alternative would be very awkward. In most cases, a proper guard is a better choice.

Common places TS2532 shows up

• Array.find results. arr.find(x => x.id === 5) returns T | undefined. You need a guard before using the result.
• Map.get results. Same story: map.get("key") may return undefined.
• Regex match results. "hello".match(/x/) returns undefined on no match.
• Object destructuring with missing keys. If the type allows an optional key, the destructured variable inherits that optionality.
• API response parsing. If your type says a nested property is optional (marked with ?), any access needs a guard or optional chain.

Which fix should you pick?

• You want different behavior for missing vs present: Fix 1 (if guard).
• You just want to safely read a nested property: Fix 2 (optional chaining).
• You have a fallback value: Fix 3 (nullish coalescing).
• The value is a function parameter and has an obvious default: Fix 4 (default parameter).
• You are certain it is defined but the compiler cannot see the proof: Fix 5 (non-null assertion), sparingly.

Fix 1 through 4 add real safety to your code. Fix 5 removes safety and should be a last resort.

Verifying your fix

npx tsc --noEmit

If TS2532 no longer appears in the output, the fix is applied. Also check your linter (ESLint with typescript-eslint) is not warning about the non-null assertion if you used one.