Paying for a Drupal theme buys you three things — a finished visual design, demo content that gets you off a blank page, and somebody contractually obliged to answer your email — and it does not buy you a different software licence, a guarantee of core compatibility, or fewer hours spent wiring the design to your content.
That sentence is the whole decision, and almost every "best themes" list skips it in favour of screenshots. I have been doing web development since 2005 and I am the author of Drupal modules and themes, some of them free on drupal.org, so I have watched this purchase go both ways. What follows is the part buyers actually need: what the money changes, what it cannot change, and the four lines you should write down before comparing anything.
The licence is the same on both sides of the transaction
Drupal core is distributed under the GNU General Public License, version 2 — that is the text sitting in LICENSE.txt in the core directory of any Drupal install you have. A theme's PHP and Twig execute inside Drupal, and the project treats extensions as derivative works, which is why contributed themes and modules distributed through drupal.org carry GPL-compatible licences. The theme I maintain declares GPL-2.0-or-later in its own composer.json.
Read that as a buyer and it changes what you think you are purchasing. A vendor selling a Drupal theme is not selling you restricted rights to the code — the GPL's terms apply to what you receive. They are selling access: the download, the updates, the demo content, the support queue, and often design services around it. That is a subscription to a relationship, not a padlock on a file.
What the money is actually paying for
| What you are buying | Free, contributed | Paid |
|---|---|---|
| A finished visual design | Whatever the maintainer's taste produced | Usually a professional design, which is the real product |
| Demo content and a starting point | Rare | Common, and genuinely saves days |
| A support commitment | An issue queue and goodwill | A contractual response, for the term you paid for |
| The software licence | GPL-compatible | GPL-compatible — the same |
| Core compatibility in two years | Depends on the maintainer | Depends on the vendor — money does not change the dependency |
| Integration hours on your content model | Yours | Still yours |
| Accessibility conformance of the finished site | Not promised | Not deliverable by a theme at all |
The bottom three rows are where budgets go wrong. A theme, paid or free, arrives knowing nothing about your content types, your view modes, your Views output or your editorial workflow. Someone bills the hours that connect them, and the size of that bill is set by how far your content model sits from the theme's assumptions — not by the price on the download page.
The three costs that dwarf the price
Integration
A design is a set of pages. A Drupal site is a set of entities rendered through view modes. The gap between them is fields, display settings, Views and template overrides, and it is the majority of every theming invoice I have ever written. A theme that lines up with your content model is cheap at any price; one that does not is expensive at zero.
The upgrade carry
Every theme is a project you carry to the next major version of Drupal. The check is the same for a free theme and a paid one: open its .info.yml and read core_version_requirement, because that is the maintainer stating support in their own words rather than a marketing page restating it late. The wider method for judging a contributed project before you adopt it is in the evaluation checklist for free Drupal themes, and it applies unchanged to something you paid for.
Handover
The expensive theme is the one only its vendor can modify. If the customisation route is an undocumented settings panel and a proprietary page builder, your next agency quotes a rebuild rather than a change. Ask for the extension mechanism before you buy: a sub-theme, a documented template structure, and CSS you can override without fighting specificity.
When paying is the right call
- You have no design capability in-house and a fixed launch date.
- The site needs to look like its sector, and the sector has a visual convention the theme already follows.
- The site has a short intended life — a campaign, a launch, a two-year marketing presence — so the upgrade carry never arrives.
- The demo content genuinely models something close to your content, rather than being stock photographs in a grid.
When it is not
- You have a content model with real structure — several types that reference each other — because the design will be rebuilt around it anyway.
- You already have brand guidelines, in which case you are paying for a design you will then override.
- You intend to keep the site five years or more, where the maintenance question outweighs the purchase.
- The site will face a procurement accessibility review, where what matters is the audit of the delivered site rather than any claim attached to a theme — the split is set out in the Section 508 audit checklist.
If you are weighing this for a real project rather than in the abstract, an hour with a Drupal architect before the purchase is worth more than the difference between any two themes on your shortlist, because the expensive mistake is never the licence fee.
Write down four lines before you compare anything
- Licence or purchase price, including any annual renewal, multiplied by how long you expect to run the site.
- Integration hours — ask whoever will build it for a number against this specific theme and your specific content model, not a generic estimate.
- Maintenance — who applies updates, and what happens at the next major Drupal version.
- Exit — what a different developer would charge to change it in year three.
In my experience the first line is rarely the one that decides the total, and it is the only one most shortlists compare. Write all four down for two candidates and the answer usually stops being interesting, which is the point.
Common questions
Are there paid themes on drupal.org?
Projects distributed there carry GPL-compatible licences, and commercial Drupal themes are generally sold from vendors' own sites and marketplaces rather than from the project pages. Inventory and vendors change, so check the seller directly rather than trusting any list, including this one.
Do I need a theme at all?
Not necessarily. A Drupal install ships with a front-end theme and an administration theme maintained by the project itself, and for a straightforward content site the front-end one is a credible answer that costs nothing and is upgraded by the same people who upgrade core. Adopt something else when you have a reason you can say out loud.
What happens if the vendor disappears?
You keep what you have and you may fork it, because the licence on the code allows it. The vendor's support terms are a separate matter: a modified copy is often no longer supported, which is a commercial term rather than a legal one. What you lose is updates, and that matters most at the next major Drupal version — the same risk a single-maintainer free project carries, so judge both the same way rather than assuming money removes it.
Does a paid theme come with accessibility conformance?
No theme can deliver that, because conformance is a property of the delivered page — your content, your modules, your images. Treat any theme advertising guaranteed conformance as a signal about the seller's other claims.
Next steps
Shortlist two themes, write the four lines for each, and ask your developer for integration hours against your actual content types. If the numbers come out close, pick the one whose extension mechanism you understand, because that is the one that will still be cheap to change in year three.
If you want the shortlist checked against your content model rather than against screenshots, Drupal services covers how that assessment is scoped, and the projects I maintain and the sites they run on are on the portfolio.