Component Names

Inspector headers that can be renamed in place

Component Names centers on a simple change that makes a scene easier to read: component headers in the Inspector can be renamed directly. A component header can be selected and renamed with F2, or through the context menu’s Rename command. That makes it possible to turn generic labels into names that match the job a component is doing in a specific GameObject.

This is especially useful when several components of the same type sit together on one object. Instead of opening each one to figure out which collider, trigger, or state handler is which, the header itself can carry the identifying text. The component still behaves like a normal Unity component, but its label can now reflect the way it is being used in the scene.

The default name remains visible in parentheses after the custom name, so the original component type is still readable. That keeps the Inspector informative while letting the custom label do the more specific work.

Names that do more than label the Inspector

The custom name is not limited to the component header. It is also shown in Object fields and in UnityEvent dropdowns, which helps keep those selection menus tied to the same naming scheme seen in the Inspector. When a project relies on multiple similarly named components, that extra clarity can reduce second-guessing during setup.

The naming format is flexible enough to support both short labels and added context. A suffix can be appended after the default name by typing it in parentheses. A custom name and suffix can be entered together, and a name can also be written without the default suffix when needed.

• Type a suffix after the default name with parentheses.
• Enter a custom name and suffix in the same field.
• Leave the parentheses empty to hide the default name suffix.

That gives the component header a practical range of uses, from compact identifiers to more descriptive labels that explain what the component is doing in a particular setup.

Tooltips and summary text on the component header

Component Names also turns the header into a place for brief guidance. A custom tooltip can be added by typing a name and tooltip separated with a vertical bar, such as Name | Tooltip. Hovering over the component header then reveals that note in the Inspector.

There is also support for summary documentation already written on a component class. When summary documentation exists, it is shown automatically as a tooltip when the header is mouseovered. That makes the component label do more than identify the element; it can also explain its purpose without forcing the user to unfold the component every time.

For components that carry a state the creator wants visible at a glance, this approach can make the header itself more informative. The component name can reflect current behavior, while the tooltip can provide a short reminder of what the component is meant to do.

Code helpers for naming from state

The package also includes code-side support for working with custom component names. Extension methods named Component.GetName And Component.SetName Make it straightforward to read or assign names in code. That keeps the naming workflow available both in the Inspector and in scripts.

One listed pattern is generating names from the current state by calling Component.SetName In OnValidate. That can be useful when a component’s visible label should mirror values already present on the object. Instead of updating the Inspector manually, the script can keep the displayed name in step with the component’s state.

It is also possible to make Component.name And Component.ToString() Return custom component names by deriving from a custom base class. That broadens the naming system beyond the Inspector itself and into the places where component names are read in code.

These helpers keep the naming workflow practical for teams that want their component labels to stay consistent without treating the Inspector as the only place where the name matters.

Builds stay clean, and custom editors still fit in

All custom name data is fully stripped from builds. That means the naming layer is for editor-time clarity rather than runtime baggage, which keeps the project’s final build free of the extra naming information.

The package is also marked as highly compatible. It works with Odin Inspector, Power Inspector, and any custom editors that may already be part of the project. That matters for teams with a customized workflow, because the naming system is meant to sit alongside those tools rather than replace them.

For artists and developers, that makes the package a straightforward way to keep complex objects readable. Component headers, object references, UnityEvent lists, and code-side lookups can all point to the same clearer naming pattern, while the build itself remains stripped of the custom data.

Component Names is set up for projects where the Inspector needs to communicate more than a default class name, and where component labels should stay useful both in editor work and in supporting scripts.

Visual Breakdown