Skip to content

Set Text, Format Text, and Text vs String vs Name

At a glance

Lives in: Blueprint API / Widget and Utilities / Text - Set Text target: a Text Block object reference - Set Text input: Text (FText in C++) - Set Text returns: no value; execution continues - Important side effect: calling it removes any binding on that Text Block's Text property - Format Text returns: a new Text value - Official docs: SetText (Text) and Format Text

The one-minute version

  • A UMG Text Block stores its displayed value as Text, Unreal's FText type. Set Text replaces that value on one Text Block.
  • Set Text has no return value or success Boolean. An invalid target is a reference error, not an empty-text result.
  • Calling Set Text removes a Designer binding attached to that Text property. Use direct event-driven updates or a binding as the owner, not both.
  • Format Text builds one Text value from a Text pattern such as Ammo: {Current}/{Maximum} and typed argument pins. It does not target a widget; feed its result into Set Text.
  • Use Text for player-facing display and localization, String for mutable character data and parsing, and Name for stable identifiers and lookups.
  • Convert numbers directly to Text or pass typed numbers into Format Text so Unreal can apply culture-aware grouping and decimal rules.
  • Empty Text is a valid value that draws no characters. It does not hide, collapse, remove, or destroy the Text Block.
  • Replicate gameplay facts, then format them in each local player's UI. Do not make an already formatted screen sentence the authoritative network state.

What Set Text actually does

SetText (Text) targets a UTextBlock. Its In Text pin accepts an FText value, replaces the Text Block's current Text property, and synchronizes that value to the underlying Slate text widget.

pseudocode of the Blueprint contract - not engine source

function UpdateAmmoLabel(AmmoTextBlock, NewDisplayText):
    if AmmoTextBlock is None:
        report an invalid reference
        return

    remove any binding from AmmoTextBlock.Text
    AmmoTextBlock.Text = NewDisplayText
    execution continues

The node returns no value. The runtime type is not a String hidden inside a generic pin: the property and input are Text in Blueprint and FText in C++. That distinction carries localization and culture-formatting behavior. The C++ setter returns void: its call shape is void UTextBlock::SetText(FText). Blueprint's Format Text result is also an FText; unlike the setter, it returns that value from a pure expression.

The target is the particular Text Block instance, not the parent User Widget and not the Widget Blueprint class. Mark the Text Block Is Variable when another graph in the widget needs a reference to call the setter.

What a Text value stores

FText is Unreal's player-facing text type. Depending on how it was created, it can carry a localization identity and a history describing how to rebuild its display string. That history supports translated text, number/date formatting, and culture changes.

This is why Text is more than a bag of characters:

localizable Text pattern: "Ammo: {Current}/{Maximum}"
typed arguments: Current = 7, Maximum = 30
result: one Text value whose display can follow the active culture

Copying an FText is inexpensive, but converting it through String can discard the history and localization identity that made it useful.

An empty Text is still a real value. Set Text with empty Text clears the displayed characters. The Text Block stays attached, retains its style and visibility, and may report a smaller desired size after layout. Use Set Visibility separately when the layout should reserve or release space.

Set Text replaces a binding

This setter has an unusually important documented side effect: it wipes the binding created for the Text property.

Suppose the Designer's Text field is bound to GetAmmoText:

Text binding owns AmmoLabel.Text
-> later event calls AmmoLabel Set Text "Reloading"
-> the Text binding is removed
-> future binding evaluations no longer restore ammo text

That is not a race and repeating the setter is not a fix. Choose one owner:

recommended event-driven ownership:
    weapon ammo changes
    -> HUD receives OnAmmoChanged(Current, Maximum)
    -> Format Text
    -> AmmoLabel Set Text

binding ownership:
    AmmoLabel Text binding
    -> reads one authoritative presentation source
    -> no direct Set Text calls target AmmoLabel

Event-driven updates are usually easier to debug and avoid evaluating a property binding when nothing changed. Always do one initial refresh after binding to the gameplay source so the label is correct before the next event.

Format Text preserves the pieces

Format Text is a pure utility node. It takes a Text format pattern and returns a new Text; it does not modify a Text Block by itself.

Type a literal pattern into its Format field:

Ammo: {Current}/{Maximum}

The node creates argument pins named Current and Maximum. Connect integer values to those pins, then connect Result to the Text Block's In Text pin:

Format Text
    Format  = "Ammo: {Current}/{Maximum}"
    Current = CurrentAmmo (Integer)
    Maximum = MagazineSize (Integer)
-> Set Text (Target = AmmoLabel)

Format arguments can retain useful types instead of forcing every value through a String first. Blueprint supports arguments including numeric values, Text, String, Name, Boolean, objects, and text gender. Numeric arguments are formatted as numbers; a Text argument remains Text.

Named placeholders make the sentence translatable as a whole. A translator can move {Current} and {Maximum} without changing the graph. Concatenating "Ammo: " + Current + "/" + Maximum fixes word order and punctuation in separate fragments, which may not work in another language.

When the Format pin is connected dynamically instead of using a literal, add the expected argument pins in the node's Details panel. Format Text has no success Boolean. Missing, renamed, or malformed placeholders produce the wrong display and can emit formatting diagnostics; keep stable patterns in localized Text assets or literals and test every dynamic pattern.

Literal braces and formatting markup need escaping according to Unreal's Text format syntax. If a displayed value can contain user-authored braces, pass it as an argument rather than splicing it into the format pattern.

Culture-aware numbers

Use typed numeric arguments or Blueprint's numeric To Text nodes for values players read. Those nodes expose formatting controls such as grouping, sign, and minimum/maximum digits, and their output follows the active culture.

good display path:
    Score (Integer)
    -> To Text (Integer, Use Grouping = true)
    -> Set Text

also good:
    Format Text "Score: {Score}"
    -> Score pin receives Integer directly
    -> Set Text

Avoid this for localized UI:

Integer -> String -> append punctuation -> Text

That path commits early to raw characters and converts the resulting String to culture-invariant Text. Use it for logs, protocol fields, or parsing when that is actually the requirement, not because an automatic conversion pin happened to compile.

For timers, decide the design rather than accepting a default float display: format whole seconds, build a minutes:seconds presentation, or use an appropriate time-to-Text path. Update only when the displayed unit changes if sub-frame precision is not visible.

Text, String, and Name answer different questions

Blueprint type C++ type Best use Main trap in UI
Text FText Player-facing words, localized patterns, culture-aware values Converting through String can lose localization history.
String FString Mutable character data, parsing, search, file/network text formats, debug assembly String-to-Text creates culture-invariant display text, not a localizable authored phrase.
Name FName Identifiers, row names, socket names, tags, parameter keys, frequent comparisons It is case-insensitive and not a player-facing localization container.

Use the meaning of the value, not its current spelling:

"Inventory.Full" lookup key -> Name
"Inventory is full" authored message -> Text
player-entered chat buffer -> String while editing/processing,
                              then culture-invariant Text for display

String to Text

Blueprint's String-to-Text conversion creates culture-invariant Text. That is appropriate for a player name, server-provided identifier, or other text that must be displayed exactly as external data supplied it. It does not invent a localization key for an authored menu sentence. Use a Text literal, String Table entry, or another localized Text source for that sentence.

Name to Text

Name-to-Text converts the identifier's spelling into non-localized display text. It can be useful for debug UI. For production UI, map an internal Name such as Weapon.Heavy to authored Text such as a localized weapon display name rather than showing the key directly.

Text to String

Text-to-String gives the currently resolved character string but discards Text history. Converting that String back to Text does not restore the original localization identity or number-format recipe. Use the conversion only when a String-only API or parsing boundary genuinely requires it.

String to Name

Names are case-insensitive identifiers, so converting arbitrary display data to Name can merge distinctions the text was meant to preserve. Do not use Name as a cheap deduplication or display-text type.

Localization-safe patterns

Keep complete authored phrases as Text and inject changing values:

Format Text "{PlayerName} captured {ObjectiveName}"
    PlayerName    = culture-invariant Text made from external player name
    ObjectiveName = localized Text from objective data
-> AnnouncementLabel Set Text

For plural-sensitive sentences, Text formatting also supports argument modifiers. Use a localized pattern that owns the whole sentence instead of choosing English singular/plural fragments in Blueprint. String Tables are a useful source when many widgets share the same authored phrase.

Keep localization identity stable. Rebuilding an authored phrase from runtime String fragments can make it impossible for the localization pipeline to find or reorder that phrase later.

Plain Text Block versus Rich Text Block

A normal Text Block displays plain Text with one configured style. Markup-looking characters are just characters; Set Text does not make a normal Text Block parse style tags or inline images.

Use a Rich Text Block when the design needs styled spans, inline images, or custom decorators. It still receives an FText value, but its configured style table and decorators interpret supported markup.

Text Block:
    simple label, score, button caption, paragraph with one style

Rich Text Block:
    "Press <InputIcon id=\"Jump\"/> to vault"
    style changes inside one paragraph

Rich Text Block's direct Set Text call also removes a Text-property binding. Treat untrusted/user-authored values as arguments or escape/sanitize them when they enter a markup-parsing widget so they cannot accidentally become markup.

Repeated updates and layout cost

Set a Text Block when the displayed fact changes:

OnHealthChanged -> update health Text once
OnObjectiveChanged -> update objective Text once
countdown crosses a displayed second -> update timer Text once

Do not put Format Text -> Set Text on Tick for a value that changes only a few times per second, and do not hide the same work in a property binding. Text changes can alter desired size, wrapping, and surrounding layout in addition to rebuilding the display string.

For a large list, update visible/reused entry widgets when their item data is assigned. Avoid having every row search gameplay state independently. For frequently reused C++ format patterns, FTextFormat can cache the compiled pattern; Blueprint beginners get the larger win first by avoiding unnecessary updates.

Multiplayer-local presentation

Widgets are local and do not replicate. Replicate the state with gameplay meaning, then let each player's UI format it:

server-authoritative facts:
    CapturingTeamId, SecondsRemaining, ObjectiveId

each client:
    resolve ObjectiveId to localized ObjectiveName Text
    Format Text using local culture
    Set Text on that client's announcement widget

Two players can use different languages and number conventions while observing the same replicated state. Replicating an already formatted English sentence throws away that local choice and couples gameplay state to one presentation.

Player names and chat supplied externally are usually culture-invariant Text; the surrounding labels and sentence patterns should still be localized Text.

When it fails (and what failure does)

Neither Set Text nor Format Text returns a success Boolean.

  1. The Text Block target is None. Blueprint can report Accessed None, and no label changes. Guard optional references with Is Valid.
  2. The wrong widget instance is targeted. A hidden duplicate changes while the visible Text Block belongs to another User Widget instance.
  3. A Designer binding stops updating. A direct Set Text call removed that binding by design.
  4. The sentence is not localizable. It was assembled as String or converted from String instead of coming from an authored Text pattern.
  5. Numbers use the wrong separators or precision. They were converted to raw String, or numeric Text formatting options were not chosen.
  6. A Format Text value is incomplete. The dynamic pattern and argument-pin names do not agree, or a literal placeholder was renamed without rewiring.
  7. Text is correct but clipped or overlapping. The containing layout, wrapping, minimum size, or localization expansion was not designed for the result.
  8. Markup appears literally. A normal Text Block was used where a configured Rich Text Block was required.

Print the final Text or inspect the target instance, but diagnose the type and ownership path before adding more setter calls.

What these nodes do not do

  • Set Text does not format placeholders, choose a culture, or translate raw String data.
  • Format Text does not find or update a Text Block.
  • Neither node creates, shows, hides, sizes, or removes a widget.
  • Neither node changes font, color, wrapping, visibility, or rich-text styles.
  • Neither node validates gameplay values or clamps numbers.
  • Neither node replicates a message or runs on another client.
  • Empty Text does not mean None, failure, or Collapsed visibility.

Lookalikes - which one do I want?

Node / type Use when Watch out
SetText (Text) Replace one Text Block's display from an event-driven path. It removes that Text property's binding.
Format Text Compose a localizable Text pattern with typed placeholders. It returns Text; it does not target a widget.
To Text (Integer/Float) Display a number with culture-aware formatting controls. Choose grouping and digit behavior deliberately.
Append / Build String Assemble mutable/internal String data or debug output. It is not the default localization path for UI sentences.
Text binding One binding deliberately owns the Text property. Direct Set Text removes it; repeated evaluation can hide work.
Rich Text Block One text run needs markup, styles, inline images, or decorators. It needs configured style/decorator data and still uses Text values.
Set Visibility Empty content should also release or reserve layout space by policy. It does not change the stored Text.

Rule of thumb: keep player-facing phrases as Text, format changing values into one localized pattern, and let one event-driven path own each Text Block.

Going deeper