Both are free, open-source PHP content management systems, so the choice comes down to the kind of site you're building. Drupal suits structured or complex sites where a configurable core and a developer-oriented framework matter. Joomla suits publishing-led sites that need multilingual support, with a framework you can also use on its own.
The question usually comes up at the start of a site build, when WordPress has been ruled out or at least questioned, and two other long-running open-source options are on the table. Drupal and Joomla have both been around for years and both are free to use, which makes the choice harder rather than easier.
Both projects say they're more than a CMS
Drupal describes itself as a web application framework as well as a content management system. Joomla says its underlying web application framework can be used independently of the CMS. In other words, both are trying to be a platform for building things, not just a place to publish pages.
That changes how you should compare them. If all you need is pages, posts and menus, either will do and the framework story is a bonus you may never touch. If you expect the site to grow into something closer to an application, with custom data and logic, the way each framework is built and documented matters far more than any list of features in the admin screen.
Core features compared
| Drupal | Joomla | |
|---|---|---|
| Licence | Free, open source | Free, open source |
| Framework | Yes | Usable on its own |
| Core extras | Registration, menus, RSS, taxonomy | - |
| Multilingual | - | Yes |
| Coding for basics | None needed | - |
| Governance | - | Volunteer departments |
Choose Drupal for structured, complex builds
It makes sense when the site has to handle a lot of structured content and you want much of the groundwork in core. Menu management, RSS feeds and taxonomy are all part of the core package, so tagging, categorising and organising large amounts of content starts from a solid base rather than a pile of add-ons.
That core list also points at the kind of site it serves well. User account registration and maintenance suits a members' area or a community section. Taxonomy suits a library of articles, case studies or resources that people filter by topic. Menu management matters once a site has dozens of sections and several people editing them, because the structure stays in one place rather than being rebuilt page by page.
It also suits teams with developers on hand. Calling itself a web application framework is a signal of how it's meant to be used: as something you configure and build on, rather than a finished product you simply fill with pages.
If WordPress is still on your shortlist, there's a separate look at how Drupal stacks up against WordPress.
Choose Joomla for multilingual publishing
It presents itself first as a system for publishing web content, and describes itself as extendable, multilingual, accessible, responsive and search engine optimised. If you're running a site in more than one language, or accessibility is a hard requirement, those are the claims to test first in a trial install.
Extendable is the word to dwell on. It means extra features are expected to come from extensions, so the quality of the extensions you pick will shape the site as much as the core does. Before you commit, list the three or four extensions your build depends on and check when each was last updated.
Its framework being usable without the CMS has a practical upside, too. A developer could build a small standalone tool on the same foundations as the site, without dragging the whole publishing system along with it.
There's also a WordPress vs Joomla comparison if you want a third option in the frame.
How much will rest on add-ons?
Put the two sections above side by side and a useful difference appears. One ships a long list of site basics in core; the other calls itself extendable and expects extensions to carry more of the load. Neither approach is wrong, but every add-on is one more thing to keep updated, check after each core update and replace if its maintainer moves on.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
So count before you choose. Write down every feature the site needs on day one, mark which ones each platform covers out of the box and which need an extension, and ask your developer to name the extensions they'd use. A build that leans on ten add-ons carries more upkeep than one that leans on two, whichever platform it runs on.
Common ground between the two
Both are free and open source, so nothing stands between you and a test install. Both describe a framework underneath the CMS, which means a developer can take either one well beyond pages and posts. Hosting, backups and updates are your responsibility with either one, unless someone handles them for you, so factor that into the decision whichever way you go.
Neither choice is permanent, but moving a large site between systems later is a big job. That's the reason to spend a couple of weeks on a fair trial now.
Questions to put to your developer
- Which of the two have you built and maintained before, and what went wrong?
- How would you handle the one custom feature we care about most in each?
- Which extensions or modules would this build rely on, and who keeps them updated?
- What does a routine update look like, and how long does it take?
- If you were unavailable for a month, who else could keep the site running?
Two test installs, side by side
Both are free to install, so the fairest test is to build the same small site twice. List the five content types you need, such as articles, events or team profiles, and create each one in both systems. Then set up the menus and categories you'd use on launch day and watch which one your editors find natural without a walkthrough.
If you publish in more than one language, add a second language to a test page in each and see how translations are managed, since that's where the multilingual claim gets its first real test. Ask whoever will maintain the site to build one small custom feature in each framework, and run one routine update on your own hosting before launch so it isn't a surprise later.
Finally, read each project's community and security pages and note how you'd get help if something broke. Then pick the one your editors and your developer both prefer, even if it loses on paper.
Frequently asked questions
Is Drupal written in PHP?
Yes. You'll want hosting that runs PHP, and a developer comfortable with it for anything custom.
Will a Joomla site work on phones?
Its own description includes responsive, so layouts are meant to adapt to smaller screens. Check your chosen template on a real phone during the trial.
Do Drupal editors need to code?
No. Basic installation and day-to-day administration need no programming skills; code comes in when you build something custom.
What should I have ready before a trial install?
Hosting that runs PHP, a list of the content types your site needs and the names of any extensions you expect to rely on. With those in hand, a side-by-side build takes days rather than weeks.
Who looks after the Joomla project?
A community rather than a single company: contributors from all over the world, organised into volunteer departments.
