UtiliKit is a Drupal module that generates utility CSS at runtime from the class names it finds in your content, so a content editor can write uk-pd--37 and get 37 pixels of padding without a build step, a deployment, or a developer.
That is the whole idea, and it is a bigger claim than it sounds, because the reason Tailwind and its relatives cannot do this in a WYSIWYG editor is not an oversight. They compile a stylesheet ahead of time from source files. Content is not a source file, and it changes after the build.
What the class syntax is
Every element opts in with the marker class utilikit, then takes utility classes shaped as uk-{prefix}--{value}, with an optional breakpoint segment.
<div class="utilikit uk-pd--20 uk-md-pd--40 uk-bg--f8fafc uk-br--12">
20px padding on phones, 40px from 768px up, a background and rounded corners
</div>The prefixes are two letters. Counted directly from UtilikitRules::getRules() in src/Service/UtilikitRules.php on 14 September 2026, there are 50 of them, grouped into twelve families: Flexbox (9), Layout (7), Sizing (6), Box Model (5), Positioning (5), Typography (5), Grid (4), Colors (3), Effects (2), Transform (2), Spacing (1) and Background (1).
Values are not from a scale. uk-pd--247, uk-mg--3d75rem (the d stands in for a decimal point), uk-wd--87vw and uk-ht--73d5pr all resolve, because the value is parsed rather than looked up. The validation pattern in UtilikitConstants is /^uk-(?:(?:sm|md|lg|xl|xxl)-)?[a-z]{2,4}--[a-zA-Z0-9\-_.%]+$/, which is the whole contract in one line.
One deliberate choice worth knowing: the sizing and positioning prefixes map to logical CSS properties — inline-size, block-size, inset-inline-start — not to width, height and left. On a right-to-left site that is the difference between a layout that mirrors correctly and one that does not.
Three rendering modes, and how to choose
| Mode | Where the CSS comes from | Use it when |
|---|---|---|
| Inline | JavaScript generates and applies styles in the browser | Building and editing. It is the shipped default. |
| Static | A pre-generated file on disk, public://utilikit/utilikit-static-style.css | Production, where you want no client-side work. |
| Head | Server-generated CSS injected into the page head per request | Containers and read-only filesystems where writing a public file is not an option. |
The head mode is the one that tells you this module has been run somewhere real. It exists because static mode needs a writable public files directory, and a containerised deployment often does not have one.
Responsive variants
Five breakpoints ship, defined in UtilikitConstants::BREAKPOINT_VALUES as minimum widths: sm 576px, md 768px, lg 992px, xl 1200px and xxl 1400px. Any prefix takes any breakpoint, so uk-lg-gc--repeat-3-1fr is a three-column grid from 992px up. Breakpoints can be switched off individually in settings to keep the generated file smaller.
If you are already comfortable organising CSS by category, this sits beside that discipline rather than replacing it — the argument for keeping structural CSS in the theme is made in the SMACSS-based categorisation write-up.
How the classes get found
In static and head modes something has to know which classes exist before it can generate a file. UtiliKit scans rendered content for the marker class and for bare uk- patterns, and can regenerate automatically when a node, a custom block or a paragraph is saved — those three entity types are listed in AUTO_UPDATE_ENTITY_TYPES, and all three triggers ship switched off, because each one adds work to every entity save.
There is also a queue worker for cron-time processing, a lock so two regenerations cannot collide, and eight Drush commands: utilikit:generate, scan, status, mode, classes, validate, clear and cache-clear. Three permissions separate the roles: access utilikit reference for the class browser, use utilikit update button for the manual regenerate control, and administer utilikit, which is the only one marked restricted.
The failure this module had to design out
Here is the interesting engineering problem, and it is recorded in the source comments with the dates. UtiliKit had the same rules written twice — once in JavaScript for inline mode, once in PHP for static and head mode. When two copies disagree, the class does one thing in development and a different thing in production, and the setting that decides which is a rendering mode nobody associates with validity.
Three cases were measured on 5 September 2026 and fixed. uk-dp--banana emitted display: banana; into the generated stylesheet while the JavaScript engine rejected it. uk-jc--between worked inline and silently produced nothing in the other two modes. uk-wd--auto rendered inline and produced no CSS at all in static and head, because allowAuto was set on different prefixes in each copy — and which properties actually accept auto was settled by asking the browser's own CSS.supports(), not by reading the spec.
PHP now owns the keyword lists and the shorthand map, and the JavaScript reads from them. That is the class of bug — one rule with two homes — that costs the most to find in a Drupal build, because everything passes in development.
UtiliKit or Tailwind?
Tailwind is the better answer when your markup lives in templates and components, you have a build pipeline, and your team is comfortable in it. Its ecosystem, tooling and documentation are far larger.
UtiliKit is the better answer when the markup that needs styling is written by editors, in the browser, after the build has run. That is the case Tailwind structurally cannot serve, and it is common in Drupal: a landing page assembled in CKEditor or Layout Builder, needing one section at a slightly different width, today.
They are not exclusive. Plenty of sites should keep a compiled framework for the theme and use runtime utilities only for editorial content.
Guardrails
The defaults are conservative and you should read them before going to production. Static and head generation is capped at 5,000 classes per request, AJAX is rate-limited to 60 requests per minute, generated CSS is cached for an hour, and use_important ships as true — utilities win by default, which matches Tailwind's behaviour and will surprise anyone expecting normal cascade order.
Six optional sub-modules ship with it: Help, Playground (a live class tester), Examples, Test Suite, a CKEditor 5 toolbar button, and an AI helper. All of them require the parent, and all match its Drupal range except the AI one, which declares ^11.2 only because its own dependency does.
Requirements
| Item | Value |
|---|---|
| Drupal core | ^11.2 || ^12 |
| PHP | >=8.1 |
| Module dependencies | None declared |
| Configuration route | utilikit.settings |
Drupal 10 is not supported, and that is deliberate. The info.yml records the reason: renderPlain() was removed in favour of renderInIsolation(), and the REQUIREMENT_* constants were replaced by the RequirementSeverity enum, which does not exist before 11.2. There is no single constraint that covers both 10.x and 12, and advertising a core version the code fatals on is worse than not being offered at all.
Common questions
Do these classes survive the text format filter?
Only if your text format allows class attributes on the elements you are using. On a restricted format such as Drupal's default basic HTML, a class attribute is stripped and the utility never reaches the browser. Check the format before concluding the module is broken.
Does it work with Layout Builder and Paragraphs?
Paragraphs are one of the three entity types with an auto-update trigger, so yes for regeneration purposes. It pairs naturally with Paragraphs Bundles, where the section-level styling comes from the Display tab and per-element tweaks come from utilities.
What happens if I mistype a class?
Nothing renders, which is the correct behaviour and also the confusing one. Run drush utilikit:validate, or use the Playground sub-module, rather than guessing.
Will it fight with my theme's CSS?
With use_important on, utilities win. If your theme is losing arguments it should be winning, that is the first setting to look at — and if the symptom is broader than one rule, the diagnostic sequence in troubleshooting sub-theme CSS applies unchanged.
Where to go next
The UtiliKit project page lists the full class reference. Install it on a development site, turn on the Playground, and try five classes before you commit to it. If you want an opinion on whether runtime utilities belong in your build at all — there are sites where the answer is no — that is a conversation worth having before you ship it: see Drupal theming or Drupal development.