html

Q: Which module provides the Odoo html widget?

Two of them. web registers a plain fallback, and html_editor force-overrides it with the real editor. Because html_editor is auto-install, the editor is what you get on any normal database, and the fallback only surfaces on minimal installations.

Q: How do I set the height of an Odoo html field?

Pass options="{'height': 300}" on the field. The widget applies the pixel height and adds overflow scrolling. There is no Studio control for it.

Q: How do I disable images or file uploads in the editor?

On Odoo 19, set the allow-family options false: {'allowImage': False, 'allowVideo': False, 'allowFile': False}. On Odoo 18 the same knobs were called disableImage, disableVideo and disableFile with inverted meaning, and the old spellings do nothing in 19.

Q: Can two users edit the same html field at once?

Yes. Set options="{'collaborative': true}" and the field syncs live between editors with visible cursors, the same mechanism Odoo Knowledge uses. The optional collaborative_trigger: 'focus' delays joining the session until a user actually clicks in.

The HTML field is Odoo's rich text editor: checklists, tables, images, slash commands. Under the hood it is two widgets wearing one name, and its options live nowhere in the documentation.

Siddharth JambukiyaOdoo Techno-Functional Consultant

August 16, 2026Updated August 16, 20266 min read

Summarize with AI

Add as preferred source on Google

Odoo 19 email template preview rendered by the html widget, showing the Credit Note Sending template body with dynamic placeholder expressions highlighted inline.

Quick Summary

The html widget name is registered twice: a plain-text fallback in web, force-overridden by the real editor in html_editor, which auto-installs everywhere.
The editor declares no supportedOptions: all 20 or so knobs, from height to codeview, exist only inside extractProps and appear in no picker or documentation.
Content with a full <html> document inside triggers the sandboxed preview automatically: the field renders in an iframe and stops being editable inline.
codeview only works with developer mode active: the option alone does not show the code toggle.
Odoo 18 XML needs review: disableImage, disableVideo and disableFile were replaced by an allow-family in 19, and baseContainer became baseContainers.
Real-time collaborative editing is one option away (collaborative), including a trigger that delays sync until focus.

Studio name	Html
Technical name	`html`
Field types	`html`
Views	form
Module	`html_editor` (auto-installed), overriding a fallback in `web`
Used in core	9 occurrences across 8 modules, including `snailmail`, `base_install_request`, `survey`, `lunch`, `website_slides`, `account`, plus every html field rendered without an explicit widget
Versions	Odoo 20.0, Odoo 19.0, Odoo 18.0, Odoo 17.0, Odoo 16.0
No-code setup	Yes, via Odoo Studio (Enterprise)
Alternatives	`html_mail`, `text`, `properties`, `char with emoji picker`

What the HTML field does

Any fields.Html in Odoo renders through this widget by default: task descriptions, quotation terms, email bodies, knowledge articles. It is the full Odoo editor, with slash-command power buttons, checklists, tables, media embedding and font styling, saving sanitized HTML into the field.

The name hides a two-layer arrangement worth knowing. The web module registers a bare fallback that renders the HTML as plain text in a textarea, and the html_editor module, which is auto_install and therefore present on effectively every database, re-registers the same name with force: true. If you have ever seen an html field render as raw markup on a stripped-down database, that was the fallback doing its job.

What this means for your team

The HTML field is where non-technical users produce customer-facing content: quotation footers, email templates, course pages, knowledge bases. Its configuration decides how much trouble they can get into. An unconstrained editor on a quotation template lets a well-meaning salesperson paste a broken Word table into every future quote; a locked-down one with images and files disabled keeps the template clean and the PDF renderer happy.

Two capabilities are chronically underused because nobody knows they exist. Height capping (height) turns unbounded description fields into tidy scrollable panels, which transforms list-heavy forms. And collaborative brings Google-Docs-style co-editing to any html field, the same machinery Knowledge uses, which is worth enabling on anything a team drafts together, from meeting notes to proposal bodies.

Setting it up in Odoo Studio (no code)

Studio can add and place HTML fields without a developer.

Open the form in Studio and drag the Html field from the Add a field panel onto the layout.
Name the field. Users get the full editor immediately: slash commands, formatting toolbar, images and tables.
Use the Properties panel for placement, label and visibility conditions like any other field.

What Studio cannot do here

Studio stops at placement. Every behavior knob on this page, editor height, disabling media, the code view, collaboration, sandboxing, exists only as an XML option, because the widget declares none of them as configurable metadata. There is no Studio checkbox for any of it.

Also out of Studio's reach: this widget's output is sanitized server side according to the field's sanitize attributes, which are Python-level definitions. If pasted content keeps losing styles or scripts, the field definition, not the widget, is what needs a developer.

Supported options in Odoo 19

Read from extractProps in html_field.js of the Odoo 19.0 html_editor module. This is the complete set the widget actually reads. None of these appear in a supportedOptions declaration, which means none show up in Studio or in the developer tools field info, and the official documentation does not list them.

Option	Type	What it does
`height`	number	Fixed editor height in pixels, with overflow scrolling added automatically.
`allowImage`	boolean	Enables images in the media dialog and pastes. Replaces 18's inverted disableImage.(default: `true`)(since Odoo 19.0)
`allowMediaDocuments`	boolean	Enables document attachments in the media dialog.(default: `true`)(since Odoo 19.0)
`allowVideo`	boolean	Enables video embeds. Replaces 18's disableVideo.(default: `true`)(since Odoo 19.0)
`allowFile`	boolean	Enables file uploads and drops. Replaces 18's disableFile.(default: `true`)(since Odoo 19.0)
`allowChecklist`	boolean	Enables the interactive checklist block.(default: `true`)(since Odoo 19.0)
`allowAttachmentCreation`	boolean	Sets allowImage and allowFile together, and wins over both because it is applied after them in the source.(since Odoo 19.0)
`baseContainers`	list	Which block elements the editor uses as paragraph containers. Renamed from 18's baseContainer.(since Odoo 19.0)
`cleanEmptyStructuralContainers`	boolean	Strips empty structural wrappers from content.(since Odoo 19.0)
`debouncePowerbuttons`	boolean	Debounces the slash-command power buttons for performance on heavy documents.(since Odoo 19.0)
`debounceHints`	boolean	Debounces the empty-block placeholder hints.(since Odoo 19.0)
`collaborative`	boolean	Enables real-time multi-user editing over the bus, with live peer cursors.
`collaborative_trigger`	string	When to join the sync session: start (immediately) or focus (when the user enters the field).
`migrateHTML`	boolean	Runs stored content through editor version migrations on load.(default: `true`)(since Odoo 19.0)
`dynamic_placeholder`	boolean	Enables the dynamic placeholder flow for template expressions.
`dynamic_placeholder_model_reference_field`	field name	Field on the current record naming the model dynamic placeholders resolve against.
`embedded_components`	boolean	Activates interactive embedded blocks in readonly renders.(default: `true`)
`sandboxedPreview`	boolean	Forces the sandboxed iframe preview. Full HTML documents in the content trigger it automatically even without the option.
`cssReadonly`	asset id	Asset bundle used to style readonly content inside its iframe, as email previews do.
`codeview`	boolean	Adds a raw-HTML toggle, but only when developer mode is also active.

Order matters for the allow-family. allowAttachmentCreation is applied after allowImage and allowFile in the source, so when both are set, the attachment-creation flag wins. And codeview is doubly gated: the option must be set and developer mode must be active, or no code toggle appears.

Working examples

A capped, scrollable description

<field name="description" widget="html"
       options="{'height': 300}"/>

The editor gets a fixed 300px frame with overflow scrolling, instead of growing as long as its content.

Text-only editing, no media

<field name="terms" widget="html"
       options="{'allowImage': False, 'allowVideo': False, 'allowFile': False}"/>

The media dialog and file drops are disabled; formatting stays. The right configuration for anything that ends up in a PDF.

Collaborative editing, Knowledge-style

<field name="minutes" widget="html"
       options="{'collaborative': true, 'collaborative_trigger': 'focus'}"/>

Multiple users edit simultaneously with live cursors. The focus trigger joins the sync session only when a user actually enters the field, saving bus traffic on rarely-edited fields; start joins immediately.

Debug-only source editing

<field name="body" widget="html"
       options="{'codeview': true}"/>

With developer mode on, a code toggle exposes the raw HTML. Without developer mode this option is inert by design.

Why some HTML fields lock themselves into a preview

The sandboxed preview is the behavior most likely to surprise a team, because it activates itself. When the field's content contains a complete HTML document, with <html>, <head> or <body> markup, the widget switches to rendering it inside a sandboxed iframe, and inline editing stops. The source drives this from two inputs: the explicit sandboxedPreview option, or a content check (containsComplexHTML). Either one engages the preview.

This is why imported email templates sometimes show as a locked preview when a hand-written template on the same model stays editable: the imported one carries a full document skeleton. Editing such content happens through the code view, which is exactly how the mass mailing and template apps arrange it, pairing sandboxedPreview with codeview.

Also from the source: migrateHTML defaults to on, running stored content through editor version migrations when it loads, and embedded_components defaults to on, activating interactive blocks like table-of-contents or video cards inside readonly renders. cssReadonly lets a view name an asset bundle that styles readonly content in an iframe, which is how email bodies preview with their real mail styling.

Version compatibility

Version	Status	Notes
Odoo 20.0	In development	Not released. Every option above is still read on the development branch; internals are renamed. Details below.
Odoo 19.0	Verified	Verified against the shipped html_editor source.
Odoo 18.0	Partial / changed	Same editor, different option names: the disable-family and baseContainer. See the upgrade note.
Odoo 17.0	Partial / changed	html fields render through the previous web_editor wysiwyg, with a different option set.
Odoo 16.0	Partial / changed	Previous-generation editor (web_editor), different options and behavior.

Upgrade note for 18 to 19: options were renamed. Odoo 18's disableImage, disableVideo and disableFile no longer exist; 19 reads allowImage, allowMediaDocuments, allowVideo, allowFile, allowChecklist and allowAttachmentCreation with inverted meaning. baseContainer became baseContainers. Custom views carrying the 18 spellings silently lose their restrictions after an upgrade, which is exactly the kind of thing an upgrade audit is for. 19 also added migrateHTML, cleanEmptyStructuralContainers and the two debounce flags.

What is changing in Odoo 20

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The notes below compare the shipped 19.0 file against the public development branch, which remains unstable until feature freeze; we re-verify this page after release.

The option surface is stable: every option listed above is still read on the development branch. The visible changes are internal renames, with the dynamic placeholder props becoming dynamicField and dynamicFieldReferenceModel, and a new pending_attachment_service handling uploads that have not been saved yet. Patches built on the 19 prop names will need a review; XML views should pass through untouched.

Common problems and fixes

Symptom	Cause and fix
The field shows raw HTML in a plain textarea	The html_editor module is missing, so the web fallback widget is rendering. Install html_editor; it is auto-install on standard databases.
The field became a locked preview and cannot be edited inline	The content contains a full HTML document, which auto-engages the sandboxed preview. Edit via codeview with developer mode, or strip the document skeleton from the content.
codeview option set but no code toggle appears	The toggle requires developer mode in addition to the option. Enable developer mode, then reopen the form.
disableImage stopped working after upgrading to 19	The disable-family options were replaced by the allow-family in 19. Rewrite as allowImage: False and review the whole option dict against the 19 names.
Styles are stripped every time the record saves	Server-side sanitization on the field definition, not the widget. Adjust the field's sanitize attributes in Python, deliberately and minimally.
Collaborative cursors never appear	collaborative not set, or the trigger is focus and nobody else has entered the field. Set collaborative: true and check the bus service is reachable behind your proxy.

HTML field vs the alternatives

Widget	Best for	Key difference
`html`	Rich text the user writes: descriptions, terms, articles, notes	Full editor with slash commands, sanitized server side
html_mail	Email template bodies	Same editor plus CSS inlining on save and mail-safe restrictions
text	Plain multiline text without formatting	No markup at all, stores clean text
properties	User-defined extra fields rather than one rich text block	Different problem: ad hoc fields, though html is one of its property types
`char with emoji picker`	Single-line text with emoji support	One line, no block formatting

The rule: user-facing rich content wants this widget, machine-facing markup wants the code view or a plain text widget, and email template bodies want html_mail, which layers mail-specific inlining on top of this exact editor.

Frequently asked questions

Which module provides the Odoo html widget?+

Two of them. web registers a plain fallback, and html_editor force-overrides it with the real editor. Because html_editor is auto-install, the editor is what you get on any normal database, and the fallback only surfaces on minimal installations.

How do I set the height of an Odoo html field?+

Pass options="{'height': 300}" on the field. The widget applies the pixel height and adds overflow scrolling. There is no Studio control for it.

How do I disable images or file uploads in the editor?+

On Odoo 19, set the allow-family options false: {'allowImage': False, 'allowVideo': False, 'allowFile': False}. On Odoo 18 the same knobs were called disableImage, disableVideo and disableFile with inverted meaning, and the old spellings do nothing in 19.

Why is my html field showing a preview I cannot edit?+

The content contains a complete HTML document, which automatically switches the widget into its sandboxed iframe preview. Edit it through the code view (with developer mode), or remove the html/head/body skeleton if inline editing is wanted.

Can two users edit the same html field at once?+

Yes. Set options="{'collaborative': true}" and the field syncs live between editors with visible cursors, the same mechanism Odoo Knowledge uses. The optional collaborative_trigger: 'focus' delays joining the session until a user actually clicks in.

Does the html widget change in Odoo 20?+

The development branch keeps the whole option surface and renames internals: the dynamic placeholder props and a new pending-attachment service. XML views should carry over unchanged. We re-verify this page once Odoo 20 ships in late September 2026.

Editor fighting your content team?

Locked-down template editors, collaborative drafting, clean PDF output, migrated email templates that survived the 18 to 19 option renames: the HTML field rewards precise configuration. We configure and extend the Odoo editor so content stays clean from draft to customer.

Get your editor configured right

How this page was produced

This page was verified by reading both registrations of the html widget in the Odoo 19.0 source, the fallback in web and the editor in html_editor, extracting the complete option set from extractProps, and diffing against 18.0 (option renames) and the development branch (prop renames only). The sandboxed preview behavior was confirmed in the component's getters. Where the documentation is silent, which is nearly everywhere for this widget, we cite the source instead. Corrections: tell us.