By @obartsch
What is your idea about?
Finding a specific image in a large TYPO3 media library today usually means already knowing (or guessing) its filename. Editors can’t search “car” and get every image that actually shows a car, because TYPO3 has no concept of what an image depicts, only what it’s called.
This isn’t a new problem in the wider CMS world, other platforms have already solved it: Drupal CMS ships AI-assisted media tagging and discovery out of the box, and Adobe Experience Manager has offered AI-based smart asset tagging for years. But every one of these implementations is cloud-only, built on a SaaS AI provider with no self-hosted option.
TYPO3 has a real opportunity here: build the one CMS-native version of this feature that takes self-hosting and data sovereignty seriously by design, not as an afterthought, which is exactly the kind of positioning TYPO3 already claims for itself.
This idea adds AI-based image understanding to the Media / File module: images get automatically analyzed by a vision model, and editors can search for image content, not just filenames. This is designed to work with self-hosted, local AI models wherever possible, so no image data needs to leave the server, with cloud providers as an optional, admin-configured alternative for those who prefer it.
It will be built as a standalone TYPO3 extension, compatible with TYPO3 13 LTS and later, so existing installations can use it right away.
What must be achieve by 30th of November 2026?
-
A background indexing pipeline that runs images through a configurable AI vision provider (local-first, cloud optional) and stores the resulting tags/description as file metadata
-
New uploads get indexed automatically; existing libraries can be (re-)indexed via a Scheduler task
-
Search integration in the Filelist/Media module so editors can find images by content, not just filename
-
An admin-configurable two-tier model: a lightweight tagging/keyword-search tier that works wherever AI is configured, plus an optional, opt-in semantic-search tier (e.g. “car” also matches “vehicle”) for installations willing to run a bit more infrastructure
-
A safe default: if no AI provider is configured at all, nothing changes and search keeps working exactly as it does in TYPO3 today
-
Clear documentation on which local models/setups are realistic on typical hosting versus what needs dedicated infrastructure
What is the potential impact of your idea for the overall goal?
-
Closes a real competitive gap. Editors coming from Drupal or Adobe-based platforms already expect to search media by content. TYPO3 currently can’t do this at all.
-
A genuine market differentiator, not just a catch-up feature. Every comparable implementation we found (Drupal CMS, Adobe Experience Manager, mainstream DAM tools) is cloud-only. Nobody in this space ships a self-hosted-first version. TYPO3 doing this properly turns “we’re behind” into “we did it the way it should have been done.”
-
Privacy by design. No image data has to leave the server, a real differentiator for TYPO3’s public-sector and privacy-conscious user base.
-
Scales to what people can actually run. Small installations get useful tagging; larger or self-hosted setups get full semantic search. Nobody is locked out, nobody is forced into infrastructure they don’t want.
-
Reusable groundwork. The AI-provider integration and indexing pipeline are generic enough that other extensions could build on the same foundation later.
How does your Idea align with the TYPO3 Association Strategy
Improves developer and editor experience by solving a real, everyday content-management pain point. Supports privacy and digital sovereignty, both core TYPO3 values, by prioritizing local/self-hosted AI over cloud dependency. Directly strengthens TYPO3’s competitive position: rather than catching up to a feature Drupal and Adobe already ship, this makes TYPO3 the one major CMS offering it in a self-hosted, sovereignty-respecting way, turning a feature gap into a differentiator.
Budget for this idea?
10.000 Euro
My Name
Oli Bartsch