Accessing Input Value from EventTarget in TypeScript

You will learn why TypeScript types event.target broadly as EventTarget | null, why not every event target has a value property, and how to narrow or assert it as an HTMLInputElement before reading its value.

Browser events can come from many different objects: inputs, buttons, forms, documents, windows, and custom event targets. TypeScript therefore uses the general EventTarget type for event.target.

EventTarget only describes objects that can receive and dispatch events. It does not promise input-specific properties such as value, checked, or files.

Also, event.target can be null, so its full type is commonly:

EventTarget | null

An <input> element is more specific than EventTarget. It is represented by HTMLInputElement, which does have a value: string property. Before using value, tell TypeScript—or prove to TypeScript—that the target is an HTMLInputElement.

The runtime console and TypeScript are answering different questions:

• The console shows the particular object that happened to trigger this event.
• TypeScript checks every object that is allowed by the declared type.

This protection prevents code from incorrectly reading .value from targets that do not support it, such as a div or document.

Think of EventTarget as a label saying, “this object can receive mail.” An HTMLInputElement is a more specific label saying, “this object can receive mail and has editable text in a value field.”

When TypeScript sees only the general EventTarget label, it cannot assume there is a value field. You must inspect the object or explicitly state that it is an input before opening that field.

Use a type assertion when the handler is only attached to an input element:

onUpdatingServerName(event: Event): void {
  const input = event.target as HTMLInputElement;
  this.newserverName = input.value;
}

as HTMLInputElement tells TypeScript to treat the target as an input. This is appropriate when your template guarantees that the event comes from this <input>.

For code that may receive events from different sources, use a type guard instead:

onUpdatingServerName(event: Event): void {
  const target = event.target;

  if (!(target instanceof HTMLInputElement)) {
    return;
  }

  this.newserverName = target.value;
}

After the instanceof HTMLInputElement check, TypeScript narrows target to HTMLInputElement, so .value is safe.

In an Angular template, another concise option is to pass the value instead of the whole event:

<input
  type="text"
  class="form-control"
  (input)="onUpdatingServerName($any($event.target).value)"
>

onUpdatingServerName(value: string): void {
  this.newserverName = value;
}

This works, but keeping DOM type handling in TypeScript is often easier to test and maintain.

Consider this guarded handler:

onUpdatingServerName(event: Event): void {
  const target = event.target;

  if (!(target instanceof HTMLInputElement)) {
    return;
  }

  this.newserverName = target.value;
}

When a user types Apollo into the input:

1. The browser updates the input element's current value to Apollo.
2. The browser dispatches an input event.
3. Angular passes that event to onUpdatingServerName.
4. event.target refers to the element where the event started: the input.
5. instanceof HTMLInputElement verifies that the target is truly an input element.
6. TypeScript now knows target has the value property.
7. target.value returns the string Apollo.
8. The component assigns Apollo to this.newserverName.

If the handler were accidentally called with an event from a non-input target, it would return before attempting to read .value.

DOM event target narrowing is useful whenever a user action provides data through an HTML element:

• Search fields: read HTMLInputElement.value as the user types.
• Checkboxes: read HTMLInputElement.checked after a change.
• File uploads: read HTMLInputElement.files from a file input.
• Textareas: narrow to HTMLTextAreaElement and read value.
• Select menus: narrow to HTMLSelectElement and read the selected value.
• Event delegation: a container handler checks whether event.target is a button, link, or input before acting.

Example for a checkbox:

onNewsletterChange(event: Event): void {
  const input = event.target as HTMLInputElement;
  this.isSubscribed = input.checked;
}

In production code, prefer patterns that make assumptions clear and keep unsafe assertions small.

Use a guard for reusable handlers

A shared handler may be called from different elements. Validate the target first:

function getInputValue(event: Event): string | undefined {
  const { target } = event;

  if (!(target instanceof HTMLInputElement)) {
    return undefined;
  }

  return target.value;
}

Use an early return

Early returns avoid deeply nested if statements:

onInput(event: Event): void {
  if (!(event.target instanceof HTMLInputElement)) return;

  this.newserverName = event.target.value.trim();
}

Pass data rather than browser events

Components are often easier to reuse when a method accepts the data it needs:

onUpdatingServerName(name: string): void {
  this.newserverName = name;
}

The template or a small adapter can extract the DOM value.

Validate user input separately

A correct type does not mean valid content. After obtaining a string, apply application rules:

const name = input.value.trim();
if (name.length === 0) {
  this.validationMessage = "A server name is required.";
  return;
}

Type narrowing checks the shape of the DOM object; validation checks whether the user's data is acceptable.

Accessing value directly on EventTarget

This fails because EventTarget does not define value:

// Error: Property 'value' does not exist on type 'EventTarget'.
this.newserverName = event.target.value;

Narrow or assert the target first.

Forgetting that target may be null

Even this is incomplete under strict null checking:

const target: EventTarget | null = event.target;
target.value;

Use an instanceof check, which handles both the element type and null:

if (event.target instanceof HTMLInputElement) {
  console.log(event.target.value);
}

Casting to the wrong element type

This compiles but can be wrong at runtime:

const input = event.target as HTMLInputElement;
console.log(input.checked);

If the handler is attached to a <select>, use HTMLSelectElement; for a <textarea>, use HTMLTextAreaElement.

Using any everywhere

const value = (event.target as any).value;

This suppresses useful type checks. It may be acceptable in a narrowly scoped Angular template expression, but prefer a specific DOM type or a runtime guard in TypeScript.

Confusing target and currentTarget

target is the element where the event originated. currentTarget is the element whose listener is currently running. With nested elements and event bubbling, they can differ. Use the one that matches your intent.

target and currentTarget also have different meanings:

// Input value: assertion
const value = (event.target as HTMLInputElement).value;

// Input value: safe runtime guard
if (event.target instanceof HTMLInputElement) {
  const value = event.target.value;
}

// Checkbox state
if (event.target instanceof HTMLInputElement) {
  const checked = event.target.checked;
}

// Select value
if (event.target instanceof HTMLSelectElement) {
  const value = event.target.value;
}

// Textarea value
if (event.target instanceof HTMLTextAreaElement) {
  const value = event.target.value;
}

• EventTarget does not contain input-specific properties.
• event.target may be null.
• Use instanceof when the event source is uncertain.
• Use as HTMLInputElement only when the surrounding code guarantees the target is an input.
• value is always a string for text, select, and textarea values; convert it when a number is required.

Why does the browser console show value but TypeScript reports an error?

The console shows the actual runtime element. TypeScript sees the broader declared type, EventTarget | null, which could also represent objects without a value property.

What is the correct TypeScript type for a text input?

Use HTMLInputElement. It includes properties such as value, checked, files, and type.

Is event.target as HTMLInputElement safe?

It is safe when you know the event handler is only used by an <input>. If the handler can be reused or invoked from other elements, use instanceof HTMLInputElement instead.

Why does TypeScript say that event.target might be null?

The DOM event type allows a missing target in some situations. A type guard such as event.target instanceof HTMLInputElement handles this automatically.

Should I use target or currentTarget?

Use target to inspect the element that initiated the event. Use currentTarget when you need the element where the listener is attached. They may differ when events bubble through nested elements.

How do I read a numeric input value?

input.value is still a string. Convert it deliberately:

const amount = Number(input.value);

Check for invalid values when needed with Number.isNaN(amount).

How do I get a value from a select element?

Narrow the target to HTMLSelectElement and use its value property.

• Type assertions — Tell TypeScript to treat a value as a more specific type when you know more than the compiler.
• Type guards — Use checks such as instanceof to narrow types safely at runtime.
• DOM events — Understand Event, event bubbling, target, and currentTarget.
• HTMLInputElement — The DOM interface that provides input properties such as value, checked, and files.
• Strict null checks — Explains why values such as event.target must be checked before use.
• Angular event binding — Connects template events such as (input) and (change) to component methods.
• Form validation — Validates the user-entered string after it has been safely read from the input.