Unity has two built-in UI systems — UGUI and UI Toolkit — and Loom is a third option that runs real HTML, CSS and TypeScript. In short: UGUI is the mature, GameObject-based system that suits world-space UI and existing projects; UI Toolkit is Unity's newer, web-inspired system; and Loom runs an actual browser engine inside Unity for teams who want the real web stack. They differ most in workflow, ecosystem and cost.
UGUI — the original Unity UI
UGUI, often just called Unity UI, has been Unity's UI system since 2014. It is built from GameObjects and Canvases, and you assemble it visually in the Scene view.
Its strengths are maturity and reach: every Unity tutorial, asset and forum answer assumes it, the Asset Store is full of ready-made UGUI components, and it handles world-space UI — interfaces placed in the 3D scene — naturally. Its weaknesses show on complex UI. A detailed screen becomes a deep tree of GameObjects, canvas rebuilds can cost performance when the UI is large or changes often, and data-heavy interfaces take a lot of manual wiring. UGUI is a safe choice for small projects and the obvious choice for existing UGUI codebases.
UI Toolkit — Unity's newer system
UI Toolkit is Unity's more recent UI system. It is retained-mode, uses UXML for structure and USS for styling, and was deliberately modelled on the web.
It uses one styling system across editor and runtime UI, suits complex, data-driven interfaces better than UGUI, and is Unity's strategic direction, so investment continues. The trade-offs: USS is a subset of CSS and UXML is an XML dialect rather than HTML, there is a real learning curve, logic is still C#, and there is no npm ecosystem to draw on. UI Toolkit is a strong default for new Unity-native UI, and especially for editor tooling.
Loom — real web UI inside Unity
Loom takes a different route. Rather than reimplementing web ideas, it embeds a GPU-accelerated browser engine in Unity and renders a real web page into the render pipeline.
That gives you real HTML, CSS and TypeScript and the full npm ecosystem — React, Solid, Vue, Tailwind — plus hot reload, where UI changes appear in Play mode in under a second, and a typed bridge generated from your C# that keeps game and UI in sync. The trade-offs are real too: Loom is a paid product and a third-party dependency, it is new where the built-in systems are mature, and if nobody on the team knows web development, UGUI or UI Toolkit is a gentler start. Loom suits teams that already think in HTML and CSS and want that to be their advantage.
UGUI vs UI Toolkit vs Loom, side by side
| UGUI | UI Toolkit | Loom | |
|---|---|---|---|
| Status | Mature, since 2014 | Newer, evolving | New, in beta |
| Structure | GameObjects + Canvas | UXML | Real HTML |
| Styling | Component inspectors | USS — a CSS subset | Full CSS |
| Logic language | C# | C# | TypeScript / JavaScript |
| Ecosystem | Unity Asset Store | Unity packages | npm — React, Solid, Vue, Tailwind |
| Iteration loop | Play mode / domain reload | Domain reload | Hot reload, under a second |
| World-space UI | Strong | Limited | Screen-space overlay |
| Cost | Free, built in | Free, built in | Paid — free during beta |
| Best suited to | Small projects, world-space UI, existing UGUI work | Editor tooling, complex Unity-native UI | Web-skilled teams, UI-heavy games, fast iteration |
When to use which
There is no single right answer — it depends on the project and the team.
Choose UGUI if…
- You are extending an existing UGUI project.
- You need a lot of world-space UI.
- The project is small and you want the most documented, asset-rich option.
Choose UI Toolkit if…
- You are building new Unity-native UI and want Unity's supported direction.
- You are building editor tooling.
- You want a retained-mode system without taking on a third-party dependency.
Choose Loom if…
- Your team knows HTML, CSS and TypeScript.
- The game has a lot of screen-space UI and you want to build it fast.
- You want real CSS, the npm ecosystem and hot reload.
Many teams will reach for more than one of these over a project's life. The question is which system carries the bulk of your game's UI — and for a UI-heavy game built by people who know the web, that is the case Loom is made for.