DocsThe editor

Design ⇄ Code and the HTML block

When to drop into raw HTML, and what it costs you.

Last updated 27 July 2026 5 min read The editor

Two different things called 'code'

Sumezi has two separate features that both involve raw HTML, and it's easy to conflate them. The Design ⇄ Code toggle in the topbar switches the whole center panel between the visual canvas and a read-only view of the compiled HTML. The HTML block is a block type you drag into your document, with a text area where you write your own markup. Related, but not the same switch.

Code view: read it, copy it, don't type in it

Switching to Code shows a line-numbered, syntax-highlighted rendering of exactly what compile() produces from your current blocks — tags, attributes, strings, HTML comments and Outlook's MSO conditional comments each get their own color. A Copy button puts the whole thing on your clipboard. There's no textarea here: it's a <pre> block, not an editor, so changes still have to happen back in Design mode.

The filename bar above it shows a slugified name (e.g. mijn-template.html) and the live compiled size in KB, next to a fixed "Bulletproof · Outlook-tested" tag.

What "Bulletproof" means: every template you build from ordinary blocks already compiles with Outlook VML button fallbacks and color-scheme/supported-color-schemes meta tags for dark mode — automatically, with zero configuration.

The HTML block: your markup, unchecked

Find it in the block palette's Advanced group. Its properties panel is a single "Custom HTML" text area, with a visible warning right underneath: "Custom HTML is not validated by the compiler." Whatever you paste is inserted as-is into the compiled email's table row — no automatic Outlook-safing, no automatic dark-mode handling, no escaping. Past that point, you own the markup.

Both are Pro-plan features, enforced on the server

Two separate capabilities are checked: html_block — does your document contain a block of type html? — and code_mode — does the HTML you submitted differ from what the server's own compiler would produce from your blocks? The second check exists because a client could otherwise bypass the block model entirely by POSTing arbitrary HTML directly to the API, without ever touching an HTML block.

Plancode_modehtml_block
Free
Pro
Business

On the Free plan, saving a template (creating or updating) that fails either check gets rejected with HTTP 402 and a JSON body identifying which limit you hit, for example:

402 response · HTML block on the Free plan
{
  "message": "HTML-blok is alleen beschikbaar op Pro en hoger.",
  "code": "plan_limit",
  "what": "html_block"
}

The same shape comes back with "what": "code_mode" if the block check passes but the submitted HTML itself doesn't match the compiler's own output.

On the Free plan, you won't even see the option

The editor checks /api/plan when it loads, and if code_mode is off it hides the Code button from the Design ⇄ Code toggle and removes the HTML tile from the block palette entirely. The 402 above is the enforcement layer behind that — it's what stops someone from getting the HTML block back by calling the API directly instead of using the UI.

If you get blocked

Back to Docs
Was this helpful?