# Choose your interface

> Decide who renders the controls around the DOCX canvas.



SuperDoc always renders the DOCX canvas. Choose how much of the surrounding interface SuperDoc renders and how much
your application owns. This choice does not change how you load, edit, or save the document.

## Compare the approaches [#compare-the-approaches]

Switch between the three approaches. The toolbar and comments panel change ownership; the DOCX canvas does not.

> **Interactive comparison: who renders the interface**
>
> SuperDoc renders the DOCX canvas in every approach. The configuration changes who renders the controls around it.

| Approach | Configuration | Who renders the controls |
| --- | --- | --- |
| Built-in | `ui: { toolbar: { container: '#toolbar' } }` | SuperDoc |
| Hybrid | `ui: { toolbar: { container: '#toolbar' }, comments: false }` | SuperDoc renders the toolbar; your application renders comments through `superdoc.ui.comments` |
| Fully custom | `ui: false` | Your application, through `superdoc.ui` |


Start with the built-in interface. Move to a hybrid or fully custom interface only for controls your application needs
to own.

## Set the interface boundary [#set-the-interface-boundary]

`Config.ui` controls which built-in surfaces render. A partial `ui` object changes only the surfaces it names. Hiding a
surface does not remove its document data or public API.

`SuperDocEditor` creates a built-in toolbar container by default. Vanilla integrations add their own container when they
want the toolbar.

## Continue with your choice [#continue-with-your-choice]

* [Use the built-in UI](/editor/built-in-ui/overview) to configure SuperDoc's toolbar and review surfaces.
* [Build a custom UI](/editor/custom-ui/overview) to connect application-owned controls to `superdoc.ui`.

A hybrid interface uses both paths: keep the built-in surfaces that fit and replace only the ones your application owns.