You open two pages in the same workspace and the toolbars are different lengths. One has an Alert button and a table control; the other stops after the lists. Nothing is broken and nothing is being sold to you — a page type carries nine formatting switches, and a switch that is off removes its button from every page of that type.
Which page types are gated at all
Read this before anything else on the page, because it decides whether the rest applies to you.
Only posts page types apply these switches. A documentation page type and an api page type allow every formatting feature, always. That is true on all three surfaces that could enforce it: the editor toolbar renders every control, the server skips validation entirely before it looks at a single block, and the Settings screen does not draw the toggles at all for a non-posts type.
That last point is the one that sends people hunting. If you administer a documentation site and go looking for these switches on your docs page type, you will not find them, and that is correct — there is no screen to find, because there is nothing to decide. Your docs authors get the full toolbar.
Posts types have one extra rule that is not one of the nine: the Form button is hidden on every posts page, regardless of the switches. There is no setting that brings it back — it is a property of the page type’s kind, like the nine themselves.
The nine switches
| Setting | Key | Default | Toolbar control it hides | What it rejects in markdown | Syntax reference |
|---|---|---|---|---|---|
| Code Block | codeBlock | On | Code Block | Fenced code blocks — ```js and friends, including ```math | Code blocks |
| Diagrams (Mermaid) | diagrams | Off | Mermaid Diagram | ```mermaid fences | Diagrams |
| Math Block | mathBlock | Off | Math Block | Inline math (``math … ``) | Math |
| Alert | alert | Off | Alert | :::note · :::tip · :::info · :::warning · :::danger containers | Alerts |
| Icons | icons | Off | Icon | {% icon %} | Embeds and icons |
| Tab Group | tabGroup | Off | Tab Group | ===tabs-container … @tab … === | Tabs |
| iFrame | iframe | Off | Iframe | {% iframe %} | Embeds and icons |
| Collapsible Block | collapsibleBlock | Off | Collapsible Block | +++ and ++> marker blocks | Collapsible sections |
| Table | table | Off | Insert Table and the table menu | Pipe tables (` | … |
Code Block is the only one that defaults on. A brand-new posts type therefore starts with code blocks and nothing else, which is the right default for a blog and a surprise for anyone expecting tables.
Mermaid is worth one sentence of its own. Internally a diagram is a code block — the one whose language is mermaid — which is why diagrams is a separate switch rather than a sub-setting of codeBlock. Turning code blocks off does not turn diagrams off, and turning diagrams off does not stop anyone writing ordinary fenced code.
What “off” looks like in the editor
The button is not grayed out. It is absent — and it is absent from the overflow More menu too, so widening the window will not bring it back. There is no error, no tooltip explaining itself and no upgrade prompt, because nothing is being sold.
If a control you expect is missing, the two questions to ask in order are: is this page a posts type? and is that feature switched on for it? Everything the toolbar can show is enumerated in the editor toolbar reference, which is the fastest way to confirm that a control exists at all before you go looking for why it is hidden.
What “off” looks like to an AI client or an import
This is the sharper half, because here the feature does not quietly vanish — the write fails.
When markdown is written into a page body from outside the editor, the server parses it, walks the document, and collects every gated feature it uses. If any of them is switched off for that page type, the whole write is rejected with a 400 and a message that names both halves of the problem:
This page type does not allow: alerts, tables. Allowed formatting features: code blocks.When the page type allows nothing at all, the second sentence reads Allowed formatting features: none.
Two write paths run that check:
| Tool | Endpoint | What it does |
|---|---|---|
fill_page_markdown | POST /api/page/:pageId/content/fill | Sets a page’s whole body — allowed only while the body is still empty |
apply_page_markdown_ops | POST /api/page/:pageId/content/ops | Applies anchored block edits, which land as tracked suggestions |
The editor’s own AI helper takes a different route to the same place. Before it writes a word, it is handed the list of features this page type disallows and told never to emit their syntax — so it produces a heading with paragraphs instead of a collapsible block, or a list instead of a table. It is prevention rather than rejection, which is why the assistant will politely decline to build you a table on a page type that has tables off; AI help in the editor covers that behavior from the author’s side, and authoring pages over MCP covers it from your own AI client’s side.
flowchart TD
T["Page type setting<br/>e.g. alert = off"]
T --> A["Editor toolbar"]
T --> B["In-editor AI assistant"]
T --> C["Server-side validation"]
A --> A1["The Alert button is not rendered —<br/>not in the strip, not in More"]
B --> B1["The system prompt forbids<br/>:::alert syntax before it writes"]
C --> C1["400 — 'This page type does not allow: alerts.'<br/>on fill_page_markdown and apply_page_markdown_ops"]
One switch, three completely different symptoms — and most people meet only one of them, which is why a missing button and a rejected import rarely get connected to the same cause.
What is never gated
These are always available, on every page type, and no switch can remove them:
- Headings, paragraphs and hard line breaks
- Bulleted lists, numbered lists and task lists
- Blockquotes and horizontal rules
- Images and figures
- Links, including internal
pageid:links - Every inline mark — bold, italic, strikethrough, inline code, highlight, keystroke, subscript, superscript
- YouTube, video and audio embeds
The Form block sits in an odd corner: the button is hidden on posts types, but the server does not reject a form written into a posts page from outside the editor. Treat the hidden button as the intended rule and do not route around it.
Turning one on
Go to Settings → Page Types, expand the posts type you want to change, and find Editor Formatting Options near the bottom of its panel. The description above it reads “Toggle which toolbar buttons are available for this page type.”
The control is a single pill holding nine small icon buttons rather than a column of switches. A button with a darker, inset background is on; a pale one is off, and hovering either tells you which is which — the tooltip reads Alert — Enabled or Alert — Disabled. Clicking one saves immediately.
Formatting options are a CMS-side setting: they change what the editor offers and what the server accepts, and they are never written into your site’s build. You do not have to publish the page type for a change here to take effect — it applies the moment you click, for everyone, on every existing page of that type. Other page-type fields do need publishing, and publishing changes explains which; this is not one of them.
Changing a switch never touches content that is already written. Turning tables off leaves every existing table rendering exactly as it did — it removes the button, so nobody adds a tenth one.
Choosing settings for a page type
There is no correct answer, only a consistent one. Pick the smallest set that the people writing this kind of page actually need, because every extra control is one more decision at the moment of writing.
If the answer keeps coming out “all nine”, the honest conclusion is that this content is documentation, and a documentation page type would give you everything with no switches to maintain. Page types sets out what else changes when you pick one kind over another, and configuring a page type walks the rest of the settings on the same screen.