# Choose your editor interface

> Decide whether to use SuperDoc's built-in UI, configure it, or build your own controls.





Every Editor integration uses the same DOCX engine, document lifecycle, and public Document API. The interface decision determines who owns the controls around the document.

> **Diagram:** The built-in UI and a custom application UI both control the same SuperDoc editor and Document API.


## Compare the options [#compare-the-options]

| Approach               | Choose it when                                                                 | Your application owns                                  | SuperDoc owns                                                         |
| ---------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------ | --------------------------------------------------------------------- |
| Built-in UI            | You need a complete editing experience quickly                                 | Product shell, document access, workflow               | Toolbar, editing surface, review controls, responsive editor behavior |
| Configured built-in UI | The built-in experience fits, but some controls should be hidden or rearranged | Product shell and toolbar configuration                | Control behavior, command state, editing surface                      |
| Custom UI              | Your product needs its own layout, controls, or workflow                       | Toolbar, panels, interaction design, application state | Document rendering, editing, public command and state controller      |

Start with the built-in UI unless product requirements clearly need custom controls. It provides the shortest path to a complete, accessible editing workflow and helps the team learn which interactions actually need customization.

## Use the built-in UI [#use-the-built-in-ui]

Choose the built-in UI for document editors, review screens, and internal workflows where the standard editing experience already fits.

You can still control the document mode, current user, modules, theme, file lifecycle, and export behavior. Configuring the built-in UI is usually a smaller and safer step than rebuilding every control.

[See the built-in UI overview](/editor/built-in-ui/overview).

## Build a custom UI [#build-a-custom-ui]

Choose a custom UI when the surrounding product experience is part of the differentiation. Examples include a focused contract approval screen, a form-like document workflow, or controls that must match an established application design system.

`superdoc/ui` exposes a framework-neutral controller. `superdoc/ui/react` adds React providers and hooks over that controller. Both stay on public v2 surfaces and operate against the same active Editor and Document API.

[Understand the custom UI model](/editor/custom-ui/overview).

## Keep the lifecycle the same [#keep-the-lifecycle-the-same]

Whichever interface you choose:

1. Create a `SuperDoc` editor with a DOCX and a visible container.
2. Wait for `onReady` before binding document-dependent controls.
3. Read state and run commands through public surfaces.
4. Inspect receipts for programmatic changes.
5. Export the DOCX and call `editor.destroy()` when finished. That tears down `editor.ui` with it, so destroy a controller yourself only if you built it with `createSuperDocUI()`.

Switching interface strategies should not change how the document is opened, represented, or saved. It changes which layer renders and owns the controls.

> **Do not rebuild the document canvas (note)**
>
> Bring your own UI means building the controls and workflow around SuperDoc. The Editor still owns DOCX rendering,
> layout, selection, and editing behavior.


For the shortest complete path, continue with the [Editor quickstart](/editor/quickstart). To own the controls, start with [Custom UI controller setup](/editor/custom-ui/controller-setup).