Quick answer: UMG anchors define a relative position on the parent canvas, but offsets from that anchor are in absolute pixels. If you use single-point anchors with large pixel offsets, your UI breaks at different resolutions. Use stretched anchors (where min and max differ) for elements that should scale, set your DPI scaling rule to “Shortest Side” with a 1080 baseline, and wrap your layout in a SafeZone widget for console/mobile support.

You design your HUD at 1920×1080, every element placed precisely where you want it. Health bar in the top-left, minimap in the bottom-right, ammo counter perfectly aligned. Then you test at 1280×720 and the minimap is cut off. At 3840×2160, everything is tiny and clustered in the center. At 2560×1080 ultrawide, there are enormous gaps. UMG anchoring is powerful, but its behavior is deeply unintuitive until you understand the relationship between anchors, offsets, alignment, and DPI scaling.

Anchors vs. Offsets: The Mental Model

Every UMG widget has four values that control its placement: Anchor Min, Anchor Max, Offset Min (position), and Offset Max (size or right/bottom edge). The anchors are normalized coordinates where (0, 0) is the top-left of the parent and (1, 1) is the bottom-right.

When Anchor Min equals Anchor Max (a single-point anchor), the widget has a fixed size in pixels and is positioned at a fixed pixel offset from that anchor point. This is the default when you drag a widget onto the canvas, and it is the source of almost every scaling bug.

Consider a health bar anchored to the top-left (0, 0) with position offset (50, 30) and size (400, 40). At 1920×1080, it sits 50 pixels from the left and 30 from the top, exactly where you want it. At 3840×2160, it is still 50 pixels from the left — but 50 pixels on a 4K display is half the physical distance it was at 1080p. The bar also stays 400 pixels wide, which was 20.8% of the screen at 1080p but only 10.4% at 4K.

DPI Scaling: The First Thing to Fix

Before adjusting any anchors, configure your DPI scaling correctly. Go to Project Settings > Engine > User Interface > DPI Scaling:

With DPI scaling configured, all your pixel offsets are multiplied by the scale factor before being applied. That 400-pixel health bar becomes 800 pixels at 4K and 267 pixels at 720p, maintaining its visual proportion.

In C++, you can access and modify DPI scaling at runtime:

// Get the current DPI scale
float Scale = GetDefault<UUserInterfaceSettings>()->
    GetDPIScaleBasedOnSize(FIntPoint(ViewportSizeX, ViewportSizeY));

// Apply to a widget programmatically
MyWidget->SetRenderScale(FVector2D(Scale, Scale));

When to Use Stretched Anchors

Single-point anchors (where min equals max) are appropriate for elements with a fixed pixel size that should stay near a screen edge: HUD icons, button prompts, small status indicators. But for anything that should fill a region of the screen or scale with it, you need stretched anchors.

A stretched anchor has different min and max values. For example, a full-width header bar would use Anchor Min (0, 0) and Anchor Max (1, 0). The widget stretches horizontally across the entire parent but stays at a fixed position vertically. The offset values now mean something different: they define the padding from the anchor edges rather than an absolute position and size.

Common anchor configurations:

Alignment: The Overlooked Property

Alignment is the property most developers overlook, and it is the one that causes the most confusion when centering elements. Alignment defines the pivot point of the widget as a fraction of its own size. An alignment of (0, 0) means the widget’s top-left corner is at the anchor position. An alignment of (0.5, 0.5) means the widget’s center is at the anchor position.

If you anchor a widget to the center of the screen with Min (0.5, 0.5) and Max (0.5, 0.5) but leave alignment at (0, 0), the widget’s top-left corner will be at the screen center, pushing the widget to the bottom-right. Set alignment to (0.5, 0.5) to truly center it.

In Blueprints, you can set alignment when creating a widget:

// In a UMG Widget Blueprint, set slot properties
UCanvasPanelSlot* Slot = Cast<UCanvasPanelSlot>(
    MyWidget->Slot);
if (Slot)
{
    Slot->SetAnchors(FAnchors(0.5f, 0.5f, 0.5f, 0.5f));
    Slot->SetAlignment(FVector2D(0.5f, 0.5f));
    Slot->SetSize(FVector2D(600.f, 400.f));
    Slot->SetPosition(FVector2D(0.f, 0.f));
}

Handling Ultrawide and Non-Standard Aspect Ratios

DPI scaling based on shortest side handles resolution differences well, but aspect ratio differences require a different strategy. On a 21:9 ultrawide display, horizontal space increases dramatically while vertical space stays comparable to 16:9. Your centered content looks fine, but edge-anchored elements may be too far from the action.

The best approach for aspect ratio variation is to use a combination of techniques:

Safe Zones for Console and Mobile

Console certification requirements (PlayStation, Xbox, Nintendo) mandate that critical UI elements stay within the “safe zone” — typically 90% of the screen area. TVs may crop the outer 5% on each side due to overscan, and mobile devices have notches and rounded corners.

Unreal provides the SafeZone widget specifically for this. Wrap your root canvas content in a SafeZone, and it automatically insets everything to the platform’s reported safe area:

// In your HUD Widget Blueprint hierarchy:
// CanvasPanel (root)
//   └── SafeZone
//       └── CanvasPanel (actual HUD content)
//           ├── HealthBar (anchored top-left)
//           ├── Minimap (anchored bottom-right)
//           └── AmmoCounter (anchored bottom-left)

You can test safe zones in the editor by enabling Debug Safe Zone in the viewport toolbar. This overlays the platform’s safe zone boundaries so you can verify that nothing critical extends beyond them.

For more control, use SafeZonePadding instead of SafeZone. It lets you apply the safe zone inset to specific edges only — useful when you want the background to extend to the screen edges but keep interactive elements safe.

“We failed PlayStation certification three times because our subtitles were outside the safe zone at 720p. Adding a SafeZone wrapper and switching to ShortestSide DPI scaling fixed every resolution-related cert failure in one pass.”

Related Issues

UI scaling issues often compound with other display-related bugs. See Automated Screenshot Capture for Game Bug Reports for how to capture the exact screen state when players report UI problems, and Bug Reporting for Multiplayer Games for handling UI bugs that only appear on specific client configurations in networked games.

Tip: Create a “resolution test” map in your project that cycles through 720p, 1080p, 1440p, 4K, and ultrawide viewports on a timer, taking a screenshot at each. Run it before every milestone build to catch anchor regressions automatically.