A content management system that manages and stores content but has no built-in front end, delivering content through APIs so it can be displayed on any channel using any technology.
A headless CMS separates content management from content presentation. Content authors create and organize content in the CMS backend. Developers build the front end with whatever framework they choose. The CMS delivers content to the front end through APIs.
In a traditional CMS, you create a page and the system renders it. In a headless CMS, you create content and it can appear anywhere: a website, a mobile app, a kiosk, a voice assistant, a smartwatch. The CMS does not care what displays the content. It stores it, structures it, and serves it on request.
When headless makes sense
Headless shines when content needs to reach multiple channels from a single source, when the front-end team needs full control over the user experience, or when the site requires performance optimization that a monolithic CMS cannot provide. It is the natural fit for composable architectures where each layer of the stack is an independent service.
What most people get wrong
Going headless adds a build step that traditional CMS users are not prepared for. There is no “preview” button that shows you what the page looks like, because the CMS does not know what the page looks like. Preview functionality has to be built separately. Content teams accustomed to WYSIWYG editing often struggle with the abstraction until proper tooling is in place.
The other mistake is going headless when there is only one channel and no plan for others. If your content lives on a single website and your team is happy with a traditional CMS, the added complexity of headless is cost without benefit.