--- title: TYPO3 Is a Headless CMS, and Has Been for 20 Years url: "https://b13.com/blog/typo3-is-a-headless-cms-and-has-been-for-20-years" description: TYPO3 has separated content from output for 20 years. Here’s why it belongs on every headless CMS shortlist, with editing and workflows built in. image: "https://b13.com/fileadmin/_processed_/6/2/csm_HeadlessCMS_Sharing_7a8fb7f142.png" date: 2026-08-24 modified: 2026-10-20 lastUpdated: 2026-10-20 --- # TYPO3 Is a Headless CMS, and Has Been for 20 Years [ TYPO3 ](https://b13.com/knowledge/typo3) [ Enterprise CMS ](https://b13.com/knowledge/enterprise-cms) [ Open Source ](https://b13.com/knowledge/open-source) TYPO3 Is a Headless CMS, and Has Been for 20 Years ==================================================== Headless Before It Was Cool ![Bild von Benni Mack](https://b13.com/fileadmin/_processed_/c/6/csm_benni_4220bf3f2e.webp) Benni Mack 20 October 2026 [ RSS Feed ](https://b13.com/rss.xml) ![A stylized illustration of a man in a suit with three head profiles, symbolizing different perspectives or ideas, set against a purple background.](https://b13.com/fileadmin/_processed_/8/3/csm_HeadlessCMS_Headerbild_c5fe90259c.webp) Ask around which CMS to pick for a headless project and you’ll hear Contentful, Strapi, Storyblok or Sanity. TYPO3 rarely comes up. Most people file it under “classic CMS”, next to the systems that render web pages and not much else. That label doesn’t hold up once you look at how TYPO3 actually stores content. **TYPO3 has kept content and output apart for more than twenty years.** Content lives in structured records rather than in one fixed page. TYPO3 renders HTML because most projects need a website on day one, and that is the only reason HTML is the default. So there’s no need to turn TYPO3 into a headless CMS. It already is one, and it was built that way long before anyone needed a word for it. Headless Is an Output Format. Structured Content Is the Architecture. ----------------------------------------------------------------------- Most of the confusion starts with the definition. A **headless CMS** manages content and delivers it through an API, without a built-in frontend. A website, an app, a kiosk, a voice assistant or an AI agent consumes the content and decides how it looks. That definition describes *delivery*: JSON over REST, GraphQL, or whatever comes along next year. It says nothing about how content is modeled, versioned, translated, approved or permissioned. The only promise is that nobody forces HTML on you. This is why the term is slippery. Is a CMS headless if it ships JSON, or Markdown, or if it *can* render HTML but doesn’t have to? Taken strictly, any system that also renders HTML wouldn’t qualify, which says more about marketing categories than about software architecture. **The architecture that matters is structured content: data with typed fields and explicit relationships, stored independently of any output.** Headless is one of the things you can build on top of it. If your content is structured that way, going headless comes down to your configuration. If it lives in HTML blobs, adding an API on top won’t help much. Why Headless Became the Default Answer ---------------------------------------- In WP Engine’s [State of Headless 2024](https://wpengine.com/downloadable/the-state-of-headless-global-research-report/), 73% of 1,015 surveyed businesses said they use a headless approach, up from roughly a third in 2019. Of those that don’t, 98% plan to evaluate it within the next year. Storyblok’s [State of CMS 2024](https://new-www.storyblok.com/mp/state-of-cms-2024) reports that over 99% of teams who switched saw improvements. Keep in mind that both surveys come from companies selling headless solutions, one of them a WordPress host. Market estimates also vary a lot: figures for 2025 range from [$1.56 billion](https://www.giiresearch.com/report/moi2118209-headless-cms-software-market-share-analysis.html) to [$3.94 billion](https://www.marketresearchfuture.com/de/reports/headless-cms-software-market-34090), depending on what each research firm counts as headless. If the size of a category depends that much on its definition, the definition deserves a closer look. Still, the reasons for the shift to headless are real. - More channels: Websites, apps, kiosks, newsletters, and now AI agents all want the same content. - Frontend freedom: Teams want React, Vue or Astro, not the CMS’s template language. - Separation of concerns: Content teams and frontend teams can move at their own speed. All three point toward structured content and flexible output. None of them requires giving up the management layer, and that is where many headless projects run into trouble. HTML Blobs and Structured Records ----------------------------------- You can see the difference most clearly in where and how the content is stored. In **WordPress**, a page’s body sits in one database field, post\_content. Since the block editor arrived, that field holds HTML with block markers embedded as HTML comments. WordPress has had a REST API for years, so you can fetch that content as JSON, but what comes back is mostly a rendered HTML string inside a JSON field. Whatever structure exists is hidden inside the blob, where other systems can’t use it. WordPress was built to publish websites and does that very well. Taxonomies and plugins like ACF or WPGraphQL add real structure on top. The core model, though, is still one document with one body for one webpage. WordPress isn’t alone. **Microsoft SharePoint** stores the entire content of a modern page in [one field](https://clearpeople.com/blog/modern-team-sites-and-pages-behind-the-scenes), as HTML with each web part’s settings packed into encoded JSON attributes. The page is a list item with metadata columns around that blob. **Joomla** stores an article’s body as HTML in its intro and full-text fields. Page builders like **Wix** and **Squarespace** go further: content and layout are one thing, edited on the page and hard to get out in any other shape. All of them are page publishers first. (Drupal, to be fair, is the exception here: its entity and field model is structured much like TYPO3’s.) In **TYPO3**, a page has no body field. A page is a node in a tree and a container for records. Each content element is its own row with typed fields: headline, bodytext, layout, language, start and end date, access group. Everything else is a relationship. Images are references to files, categories are references to category records, a translation points to its source, and one content element can be referenced from several pages. Custom content types can get their own fields and tables, and their relationships are stored as relations in the database instead of links buried in markup. | | **WordPress (core)** | **TYPO3 (core)** | |---|---|---| | Unit of content | A post or page with one body field | A structured record with typed fields | | Where structure lives | Inside the HTML (block comments) | In the data model (tables and fields) | | Relationships | Taxonomies and post meta; anything in the body is markup | Explicit relations between records, files, categories and translations | | Translations | Plugins | Built in, each translation linked to its source | | Versioning and staging | Revisions per post | Workspaces across records and pages | | Default output | HTML | HTML, or any other format you configure | Once content is stored as structured data with explicit relationships, rendering it as JSON is mostly a matter of writing another template. What TYPO3 Already Does ------------------------- TYPO3 was never designed around the idea that output means a web page. Here is what that makes possible today: - **Any format, same content.** TYPO3 can serve the same page as HTML, XML, RSS, JSON or plain text. Each format is another rendering definition on top of the same structured records, so there’s no duplicate content and no second system. - **Templates aren’t tied to HTML.** Fluid, TYPO3’s templating engine, renders text. Whether that text is HTML, JSON or Markdown is up to you. - **A full JSON API, if you want one.** [EXT:headless](https://github.com/TYPO3-Headless/headless), maintained in the community and sponsored by Macopedia, turns TYPO3 into a JSON content API: pages, content elements, navigation, forms, SEO metadata, redirects. It pairs with [nuxt-TYPO3](https://t3headless.macopedia.io/nuxt-typo3) for a Vue frontend, but any frontend works. - **Both at once.** EXT:headless has a mixed mode: the same site answers with HTML for browsers and JSON for clients that send Accept: application/json. You don’t have to choose on day one. - **Markdown for machines.** Our own [b13/ai-bots-love-markdown](https://github.com/b13/ai-bots-love-markdown) exposes every page as Markdown via standard content negotiation. Within a day of enabling it on b13.com, bot traffic shifted to the Markdown version. ([More on that here](https://b13.com/knowledge/the-internet-is-no-longer-just-for-humans-ai-bots-love-markdown).) None of this required changes to TYPO3 itself, only additional output definitions on top of the same structured content. **When going headless is a configuration change instead of a migration, the system was headless to begin with.** What Pure Headless Makes You Rebuild -------------------------------------- Most headless pitches say little about what happens before content is published. An API is the easier half of a CMS. The harder half covers who may edit what, who approves it, when it goes live, how it looks in context, and which language version belongs to which source. All of that depends on structured data and relationships as well: permissions attach to records and fields, and translations are linked to their originals. Many API-first systems started on the delivery side and are still building out the management side, so teams end up adding preview environments, approval steps and permission logic around the CMS. TYPO3 started on the management side: - **Visual preview for editors.** Editors see their content rendered in context because TYPO3 can render it, and that still works when the production frontend is decoupled. - **Workspaces.** Prepare changes across many pages and records, preview them together, send them through review stages, publish them in one go. - **Scheduling.** Every record can have a start and end time, so content appears and disappears automatically, per element as well as per page. - **Permissions that go deep.** Access per page tree, per table, per field, per language. Large organizations with hundreds of editors run on this. - **Localization as part of the model.** Translations are records linked to their source, so you always know what was translated from what and which translations are outdated. Large organizations choose a CMS for exactly these features. In TYPO3 they’re part of the Core, and they work the same whether the output is HTML, JSON or a format that doesn’t exist yet. Bring Your Own Everything --------------------------- The first generation of headless CMSes shipped an API and a form-based editor, and preview was the biggest gap. Most frontends were static site generators, so seeing a draft meant waiting for a build. [Netlify describes](https://www.netlify.com/guide-to-composable-architecture/content-editing/headless-editing-experiences/) editors on large sites saving a change and waiting several minutes before they could see it, and [Strapi’s own tutorial](https://strapi.io/blog/handling-previews-in-a-headless-architecture) names the same problem. Forms, redirects, sitemaps, search and SEO tags were left to the project team as well. Today the standard fix is a preview mode that developers build into the frontend: a draft-mode route, secret tokens, preview URLs configured in the CMS, and usually a separate preview deployment ([Contentful’s Vercel guide](https://www.contentful.com/help/apps/vercel-app/) walks through it). Visual editing came later, mostly as a paid add-on or as a bridge you integrate into your own frontend: | **CMS** | **Model** | **Visual editing / preview** | **Costs and licensing** | **Lock-in to watch** | |---|---|---|---|---| | [Contentful](https://www.contentful.com) | SaaS only | [Live Preview](https://www.contentful.com/blog/see-your-content-come-to-life-with-live-preview/) needs your frontend and SDK; Studio visual editor is a paid add-on on top plans | Free, then [$300/month Lite](https://www.contentful.com/help/admin/usage/usage-limit/); Enterprise on request | Now owned by [Salesforce](https://www.salesforce.com/news/stories/salesforce-signs-definitive-agreement-to-acquire-contentful/) (closed September 2026) | | [Sanity](https://www.sanity.io) | SaaS content store, open-source editor UI | Visual editing requires integrating Sanity’s tooling into your frontend | Free, then [$15 per seat/month](https://www.flowninja.com/blog/sanity-cms-pricing); Enterprise on request | Content lives in Sanity’s cloud; proprietary GROQ query language | | [Storyblok](https://www.storyblok.com) | SaaS only | [Visual Editor](https://www.storyblok.com/docs/concepts/visual-editor) built in, but loads your frontend in an iframe via their bridge script | Tiered SaaS plans | Frontend code coupled to their SDK and bridge | | [Strapi](https://strapi.io) | Open source (MIT) or Strapi Cloud | Bring your own | Free core; [review workflows, SSO, audit logs](https://openapps.pro/apps/strapi) are paid Enterprise features | Workflow and governance behind a license key | | [Payload](https://payloadcms.com) | Open source (MIT) | Bring your own | Free | [Acquired by Figma](https://www.crainsgrandrapids.com/news/technology/grand-rapids-tech-firm-acquired-by-san-francisco-web-designer) in 2025; roadmap now tied to a design-tool company | These are good products, and Storyblok had visual editing from the start. Still, a pattern shows up. Preview is a separate deployment you build and host, approval workflows often cost extra, and your structured content lives in a vendor’s cloud, priced per seat or per API call. Vendors also change owners: Contentful, founded in Berlin, is now [part of a US CRM company](https://www.shopifreaks.com/salesforce-to-acquire-content-platform-contentful-adding-a-native-api-first-content-layer-to-customer-360-and-agentforce/), which raises sovereignty questions for European public-sector customers. TYPO3 had shipped all of this from the beginning. Preview, workspaces, forms, redirects, sitemaps and SEO fields are part of the Core. And as a community-driven open-source project, TYPO3 can’t be bought by anyone. Composable, Before That Had a Name Too ---------------------------------------- The same applies to “composable”, which means building experiences from reusable, independent building blocks instead of monolithic pages. TYPO3 content has always worked this way. A page is a composition of content elements, and each element is a structured record of its own. It can be reused on other pages, referenced across sites, translated, hidden, scheduled and versioned independently. With our [container](https://github.com/b13/container) package, elements can be nested into grids and groups. The nesting is stored as a relationship, so each element stays independent. Defining new building blocks keeps getting simpler.[ TYPO3 allows you to do this with simple PHP files, via Content Blocks](https://github.com/FriendsOfTYPO3/content-blocks) or via a GUI for site owners. This semantic layer is easy to overlook. A “Product teaser” or an “Event date” is a typed record with meaning and relationships rather than a styled box, and that is what an app, a search index or an [AI agent needs](https://b13.com/knowledge/the-internet-is-no-longer-just-for-humans-ai-bots-love-markdown). Open Source, Self-Hosted, Boringly Reliable --------------------------------------------- Most headless products are SaaS. That’s convenient until you need to know where your content lives, who can read it, or what happens when pricing changes. **TYPO3 is open source under the GPL, with no license fees, API call quotas or vendor setting your roadmap. You can run it on your own hardware, in your own cloud or with a hosting partner. Every LTS release comes with predictable long-term support, so a headless backend set up today won’t force a migration next year.** It also holds up at scale. The German federal government’s [Government Site Builder 11](https://www.web-vision.de/en/gsb-11.html), the standard CMS for federal authorities, is built entirely on TYPO3. More than 500 federal authorities [can use it](https://jweiland.net/en/aktuelles/artikel/bundesverwaltung-setzt-auf-typo3-fuer-webseiten.html), and its source code is public on Open CoDE. The decisive factors named for choosing TYPO3: security, flexible user rights, workflow management, and accessible, multilingual sites. Public institutions make choices like this for decades, which says a lot about how long they expect TYPO3 to be around. So, Is TYPO3 a Headless CMS? ------------------------------ Yes. TYPO3 stores structured content with explicit relationships, independent of any output. It delivers that content as JSON, Markdown or HTML on request, and it has handled editing, preview, workflows, permissions and translations for a long time. It just never marketed itself that way. Because it rendered HTML by default, most people assumed that was all it could do. So the next time you shortlist headless CMS options, put TYPO3 on the list. It’s a content platform that had this architecture long before the category had a name. ### Making an Informed Choice on Headless If you’re weighing up a headless setup and want to see how TYPO3 fits your channels, get in touch for a free consultation. We’re happy to think it through with you. [ Get in touch ](https://b13.com/lets-connect) ### Written by: ![Bild von Benni Mack](https://b13.com/fileadmin/_processed_/c/6/csm_benni_66cce9a81f.webp) b13 co-founder and TYPO3 CMS Core Development Lead, Benni Mack, heads our technical practices, setup and maintenance of our technical infrastructure, and coordinates our open-source contribution. His essential tool: TYPO3 Benni Mack CTO [ more from Benni Mack ](https://b13.com/team/benni-mack)