Using Tailwind Arbitrary Values for Responsive Styling Without Config Changes

The problem: one‑off design tweaks that bloat the config

You need a brand‑specific teal for a single badge, a 13 px gutter for a lone grid, or a 0.875 rem line‑height on a marketing headline. Adding each of those to tailwind.config.js works, but the file grows, the design system drifts, and every new value forces a rebuild of the whole utility set.

Thesis: arbitrary values let you stay in markup and keep the build lean

Tailwind v2.1 introduced arbitrary value syntax — bg-[#0d9488], p-[13px], leading-[0.875rem] — so any CSS value can be used directly in a class name. The Just‑In‑Time (JIT) compiler only emits the utilities that actually appear in your templates, so the output CSS stays minimal and no config edit is required.

How arbitrary values work under the hood

• Syntax: [value] wrapped in square brackets after the utility prefix (e.g., text-[#ff6b35]).
• Responsive variants: combine with breakpoint prefixes — md:bg-[#0d9488], lg:p-[13px].
• Tree‑shaking: the JIT scans source files, extracts every class string, and writes only those declarations to the final stylesheet.
• No config needed: works out of the box as long as JIT is enabled (default since v3.0, opt‑in via mode: 'jit' in v2.x).

Worked example: a responsive product card

Assume a card component that needs a custom accent color only on medium screens and a tighter padding on large screens.

<article class='rounded-lg shadow-md bg-white md:bg-[#0d9488] md:text-white lg:p-[13px] lg:gap-[0.875rem] p-4 gap-2'>
  <h3 class='text-xl font-semibold'>Product Name</h3>
  <p class='text-sm'>Short description…</p>
</article>

What happens:

1. md:bg-[#0d9488] generates a @media (min-width: 768px) rule that sets the background color.
2. lg:p-[13px] and lg:gap-[0.875rem] generate matching @media (min-width: 1024px) rules.
3. Base utilities (p-4, gap-2) remain unchanged.

Only those four declarations appear in the compiled CSS — no extra color palette entries, no unused spacing scale.

Trade‑off: consistency vs. convenience

Arbitrary values are a power tool. Overuse erodes the single‑source‑of‑truth that a design token system provides. Teams should:

• Reserve them for true one‑offs (marketing landing pages, A/B test variants).
• Document any recurring arbitrary value in the config after the first use.
• Enforce a lint rule (e.g., tailwindcss/no-arbitrary-values) to flag new ones in PR reviews.

Verifying the output locally and in CI

Run the compiler in debug mode to see exactly which utilities were generated:

# Run from the project root (requires Node ≥ 14, write permission to output dir)
npx tailwindcss -i ./src/input.css -o ./dist/output.css --debug

Expected checks:

• The console lists each arbitrary class (e.g., md:bg-[#0d9488]) under 'Generated utilities'.
• Open dist/output.css and search for /*! */ comments — they mark JIT‑generated rules.
• Compare file size before and after adding arbitrary classes; the delta should match the number of new declarations (roughly 150‑200 bytes each).

Risk: If CI builds with mode: 'jit' disabled (legacy v2 default), the arbitrary classes will be omitted and the UI will fall back to the base styles. Ensure the same Tailwind version and JIT flag are used everywhere.

Actionable next step

Pick a single component that currently reaches into the config for a one‑off color or spacing value. Replace that config entry with an arbitrary value in the markup, run the debug build, and confirm the generated CSS contains only the new rule. Then decide — keep it as a one‑off or promote it to the design system.