Top 60 Tailwind CSS Interview Questions (2026)

Tailwind CSS is a utility-first CSS framework. Instead of writing custom rules in a separate stylesheet, you style elements by composing small single-purpose classes like flex, p-4, and text-center directly in your markup, and each class maps to one CSS declaration. You get styling and structure in one place, which is the core departure from traditional CSS.

The difference from plain CSS is where the styling lives and how consistent it stays. You don't invent class names or context-switch to a separate file, and every value comes from a shared token scale, so spacing and colors stay uniform across a project.

Utility-first means you build designs out of many small, single-purpose classes rather than a few semantic component classes like .card or .btn. Each utility does exactly one thing: mt-4 is margin-top, text-lg is font size, rounded is border-radius. You assemble the final look from these primitives right on the element instead of naming a component and styling it elsewhere.

You compose them on the element to get the final look. The trade is more classes in the markup for no custom CSS to write, name, or maintain, and a design that stays inside your token scale.

Install it as a dev dependency, then wire it into your build so it can scan your files and generate CSS. In a typical setup you install tailwindcss, add its plugin to your CSS or PostCSS pipeline, and import Tailwind in your main stylesheet.

In Tailwind v4 the entry is a single @import "tailwindcss" line and the build detects your content automatically; in v3 you configure a content array in tailwind.config.js and include the @tailwind directives.

Most classes follow a property-then-value pattern. The prefix names the CSS property (or a shorthand of it) and the suffix names the value: mt-4 is margin-top, px-6 is horizontal padding, and text-red-500 is text color. The consistency is the point, because once you learn the shorthands the class names become predictable rather than something to memorize one at a time.

Once you learn the shorthands (m margin, p padding, w width, h height, t/b/l/r for sides, x/y for axes) you can guess most class names instead of memorizing them.

Tailwind's spacing scale maps small integers to rem values so padding, margin, width, height, and gap all pull from the same consistent set. By default each step is 0.25rem, so p-4 is 1rem (16px) and mt-2 is 0.5rem (8px). The number isn't pixels directly, it's a scale step, which is what keeps spacing uniform across every element in an app.

Using the scale instead of arbitrary pixel values is what keeps spacing consistent across a whole app. The same numbers work for p-, m-, gap-, w-, and h-.

Colors are named plus a numeric shade running from 50 (lightest) to 950 (darkest), like blue-500 or gray-800. The same scale applies to text, background, border, and ring utilities, so text-blue-600, bg-blue-100, and border-blue-300 all draw from one palette. Because every hue shares this scale, picking a readable pairing such as dark text on a light shade is straightforward and stays consistent.

Because every color shares this scale, picking accessible pairings (dark text on a light shade of the same hue) is straightforward and consistent.

Tailwind is mobile-first. A class with no prefix applies at every size, and a breakpoint prefix like md: or lg: adds a style from that width up. So block md:flex is block on small screens and flex from 768px wider.

The default breakpoints are sm 640px, md 768px, lg 1024px, xl 1280px, and 2xl 1536px, each a min-width. You layer changes on as the screen grows rather than overriding down.

Use a state variant prefix on any utility. hover:bg-blue-700 changes the background on hover, focus:ring-2 shows a focus ring, and disabled:opacity-50 dims a disabled control. The variant applies the utility only while the element is in that state, so you cover pseudo-classes without writing a single CSS rule yourself. Variants also stack with responsive ones for finer control.

Variants stack with responsive ones, so md:hover:underline underlines on hover at medium screens and up. This is how Tailwind covers pseudo-classes without writing any CSS rules.

Add flex to make the container, then compose direction, alignment, and spacing utilities: flex-row or flex-col for direction, items-* for cross-axis alignment, justify-* for main-axis distribution, and gap-* for spacing between items. Each utility maps one-to-one onto a CSS flexbox property, so if you already know flexbox you effectively know the class names without extra study.

This maps one-to-one onto the CSS flexbox properties, so if you know flexbox you already know the class names.

Use grid to set display:grid, grid-cols-* for the number of columns, grid-rows-* for rows, and gap-* for spacing between cells. So grid grid-cols-3 gap-4 makes a three-column grid with even gaps, and col-span-* lets an item stretch across multiple columns. It mirrors CSS Grid directly, so the utilities read like the properties they set.

Combine with responsive prefixes for layouts that reflow: grid-cols-1 md:grid-cols-3 stacks on mobile and spreads to three columns on wider screens.

Font size is text-* (text-sm, text-base, text-lg, text-2xl), weight is font-* (font-medium, font-bold), alignment is text-left, text-center, or text-right, and color is text-* with a color name. Line height (leading-*), letter spacing (tracking-*), and case transforms (uppercase, capitalize) each have their own utilities, so you control the whole type treatment from the class list.

For long-form article content, the official typography plugin adds a prose class that styles raw HTML sensibly in one shot.

w-* and h-* set width and height from the sizing scale, with special values for common needs: w-full is 100%, w-screen is 100vw, w-1/2 is 50%, and w-64 is a fixed scale step. min-w-*, max-w-*, and their height twins constrain sizing.

Fractional widths (w-1/3, w-2/3) are handy inside flex and grid layouts without doing the percentage math yourself.

border adds a 1px border, border-2 makes it thicker, border-gray-300 colors it, and border-t or border-b limit it to one side. Rounded corners use rounded for a small radius, rounded-lg for larger, rounded-full for pills and circles, and rounded-t-* to target specific corners. Combined with a shadow utility, that's usually all a card needs.

Shadows come from shadow, shadow-md, and shadow-lg, so a card is often just rounded-lg shadow-md p-6.

Arbitrary values let you use a one-off value that isn't in your theme scale by putting it in square brackets: top-[117px], bg-[#1da1f2], w-[42rem], or grid-cols-[1fr_2fr]. Tailwind generates a matching class on demand and still supports variants on it. Reach for them sparingly, for a genuine one-off like a brand color from a design, not as a substitute for extending the theme.

Reach for them sparingly, for a genuine one-off like a brand color or a magic number from a design. If you find yourself repeating the same arbitrary value, add it to the theme instead.

Yes, you stack as many utilities as you need in the class attribute, and their order in the string doesn't matter. Tailwind's generated CSS source order decides precedence, not the order you type the classes on the element. What does bite is putting two conflicting utilities for the same property on one element, like p-2 p-4, because then the outcome depends on generation order, not your intent.

What does matter is conflicting utilities on the same property: if you write p-2 p-4, one wins based on the CSS source order, not the attribute order, so avoid putting two values for the same property on one element.

Inline styles like style="margin-top:16px" set raw CSS on one element with no system behind them. A Tailwind class like mt-4 instead pulls from a shared token scale, supports hover, focus, and responsive variants, and gets stripped from the build if unused. The decisive gap is that inline styles can't express hover states or media queries at all, while utilities like hover:bg-blue-700 and md:mt-8 can.

You can't write hover or media queries in an inline style, but you can with utilities (hover:bg-blue-700, md:mt-8). That's the core reason utilities beat inline styles for anything beyond a true one-off.

gap-* sets the CSS gap property and works inside flex and grid containers, spacing children evenly without adding margin at the edges. space-x-* and space-y-* instead add margin between adjacent siblings using a selector, so they work even outside grid or flex layouts. gap is the modern default for flex and grid, and you reach for space-* mainly when you're not in one of those containers.

gap is the modern default for flex and grid layouts. Reach for space-* mainly when you're not in a flex or grid container or need finer per-axis control.

container sets an element's max-width to match the current breakpoint, giving you a centered, width-limited content column that steps up at each breakpoint. It doesn't center itself by default, so you usually pair it with mx-auto and some horizontal padding.

It's a quick way to keep page content from stretching edge to edge on large screens without writing media queries.

The display utilities are the main tool: hidden sets display:none and removes the element from layout, while block, inline, inline-block, flex, and grid switch it back on. Combined with breakpoint prefixes you get responsive show and hide, like hidden md:block to reveal something only on wider screens. For hiding while keeping the space, invisible sets visibility:hidden instead.

The pattern you'll write most is a mobile menu that's hidden md:flex, so it collapses on phones and appears on desktop. Keep sr-only in mind for content that should stay available to screen readers even when visually hidden.

opacity-* sets the whole element's opacity, from opacity-0 (invisible) to opacity-100 (solid), which is handy for disabled and hover states. For a color that's transparent on its own, use the slash syntax on a color utility: bg-black/50 is black at 50 percent alpha, and text-white/70 is white at 70 percent. That way the background fades without dimming the element's text or borders.

The slash-alpha form is the modern approach and reads clearly, so a translucent overlay is just bg-black/60 rather than a separate opacity element stacked behind the content.

Tailwind scans your source files, finds the class names you actually use, and generates CSS only for those. Classes you never write never reach the output, so a large real-world site often ships only a few kilobytes of Tailwind CSS.

The catch is that Tailwind looks for complete class strings in your files. Building class names by string concatenation at runtime can hide them from the scan, so they get dropped.

It's the config file where you customize Tailwind: the content paths it scans, theme values (colors, spacing, fonts, breakpoints), plugins, and dark-mode strategy. In v3 nearly all customization happens here, and the two edits you make most are extending the theme with brand tokens and pointing content at your template files so the build finds every class you use.

The most common edits are extending the theme with brand colors or fonts and pointing content at your template files so purging finds every class.

Values placed directly under theme replace Tailwind's defaults for that key entirely, while values under theme.extend add to or override individual entries while keeping the rest of the defaults. This matters because setting colors directly under theme wipes the whole built-in palette, whereas extend just adds your brand color on top. Use extend almost always to avoid losing the defaults by accident.

Use extend almost always, so you add brand-blue without losing the built-in color palette. Set a key directly under theme only when you truly want to throw out the defaults, like defining a fully custom spacing scale.

@apply inlines existing utility classes into a custom CSS rule, so you define .btn-primary once and reuse it as a single class. It's handy when the same long class string repeats across many places and you can't extract a component, or for styling base elements globally. The caution is that heavy @apply use rebuilds the very CSS files Tailwind was meant to shrink, so extracting a component is usually cleaner.

The caution: don't reach for @apply reflexively. If you're in a component framework, extracting a real component is usually cleaner, and heavy @apply use recreates the very CSS files Tailwind was meant to shrink.

Prefer a real component (a React, Vue, or template partial) when you're in a framework: it keeps the utilities visible, supports props for variants, and avoids growing a parallel CSS file. Reach for @apply mainly for small, framework-free reuse or for base element styles.

The rule of thumb: repetition of markup means extract a component; repetition of just a class string in a plain HTML or CSS setting means @apply.

Tailwind organizes generated CSS into three layers: base (element defaults and resets), components (reusable class-based patterns), and utilities (the single-purpose classes). The @layer directive lets your custom CSS join the right layer so precedence stays predictable. Layer order controls conflicts too, since utilities come last and can therefore override a component class, which is usually exactly the behavior you want.

Putting your base element styles in the base layer and your reusable class patterns in the components layer keeps your custom CSS from fighting the utilities, because the cascade order is defined for you rather than left to source position.

Use the dark: variant on any utility, like dark:bg-gray-900 dark:text-gray-100, and Tailwind applies it only in dark mode. By default dark mode follows the OS setting through the prefers-color-scheme media query, which needs no JavaScript. Switch to class-based mode (darkMode set to class or selector) when you want a manual toggle that lets users override their system preference.

In class mode you set darkMode: 'class' (or 'selector' in v4) and toggle a dark class on the html element, which lets users override their system preference.

Extend the theme's colors so the value becomes available across every color utility at once. Once brand is defined under theme.extend.colors, bg-brand, text-brand, border-brand, and ring-brand all work, and you can define it as an object of shades for a full 50-to-950 scale. In Tailwind v4 you can do the same thing in CSS with an @theme block, defining the color as a custom property.

In Tailwind v4 you can do this in CSS with the @theme block instead of the JavaScript config, defining colors as CSS variables.

the mobile layout using unprefixed classes, then layer breakpoint variants to reshape it comes first. A grid that goes one column on phones and three on desktop is grid-cols-1 md:grid-cols-3, and a nav that stacks then spreads is flex-col md:flex-row.

Because Tailwind is mobile-first, you write the simplest layout first and add complexity upward, which usually produces less code than fighting a desktop layout down to mobile.

group lets a child react to a parent's state. Add group to the parent, then use group-hover: (or group-focus:) on a child so hovering the parent styles the child. It's how you build a card where hovering anywhere reveals an icon.

For sibling-driven state there's peer, which works the same way but based on a sibling element, common for styling a label based on an input's state.

peer marks a sibling element so another element can style itself based on that sibling's state. The classic use is a form input marked peer and an error message styled with peer-invalid: or peer-focus:, so validation feedback appears without any JavaScript. It's the sibling counterpart to group, which reacts to a parent's state instead of a sibling's, and the two cover most stateful styling.

peer only reaches later siblings in the DOM because it relies on the CSS sibling combinator, so order your markup accordingly.

transition enables smooth animation on properties that change, and you tune it with duration-*, ease-*, and delay-* utilities. Pair it with a state variant so the change animates: hover:scale-105 transition duration-200 grows an element smoothly on hover instead of jumping. Tailwind also ships ready-made keyframe animations like animate-spin, animate-pulse, and animate-bounce for loaders and skeletons.

Tailwind ships a few keyframe animations (animate-spin, animate-pulse, animate-bounce), and you add custom ones through the theme's keyframes and animation keys.

The typography plugin adds prose classes to style raw HTML (blog content, markdown output) without styling every tag. The forms plugin gives form controls a sensible reset so they're easy to style. Container queries and aspect-ratio helpers round out the common set.

Knowing these exist and when to reach for them (prose for article bodies, forms for input styling) indicates real Tailwind experience.

Register it in the utilities layer with @layer utilities in your CSS, or add it through a plugin in the config. A custom utility behaves like a built-in one: it gets variant support so hover: and md: prefixes work on it, and it's stripped from the build if unused. In Tailwind v4 the @utility directive in CSS is the direct route; in v3 you use addUtilities inside a plugin.

In Tailwind v4 the @utility directive in CSS is the direct way; in v3 you use addUtilities inside a plugin in the config.

Prefix the utility with ! to mark it important, like !text-red-500, which raises its precedence when a stubborn third-party style keeps overriding it. You can also set a global important flag in the config to make every utility important, though that's a blunt instrument. Treat ! as a last resort, since reaching for it often means a deeper specificity or layer-ordering problem you should fix instead.

Treat it as a last resort. Reaching for ! often signals a deeper specificity or ordering problem, and interviewers may probe whether you understand why the conflict happened.

Extract repeated markup into components so the class string lives in one place, and use variant props to switch styles. For conditional classes, a helper like clsx or a tailwind-merge utility keeps the logic readable and resolves conflicting classes predictably.

The goal is to avoid copy-pasting a 15-class string across ten files, which is a maintenance problem regardless of framework.

Build the class string from expressions, usually with a helper like clsx or classnames so truthy conditions add classes cleanly. The key rule is that the full class name must appear as a literal somewhere Tailwind can scan, so avoid piecing class names together from fragments.

Writing bg-red-500 conditionally is fine; writing bg-${color}-500 is the pattern that breaks purging because the scanner never sees the complete class.

relative, absolute, fixed, and sticky set the CSS position property, and top-*, right-*, bottom-*, left-*, plus inset-* place the element within its positioned ancestor. z-* controls stacking order (z-10, z-50), pulling from a small scale by default. A common pattern is a relative parent with an absolute child, such as a status badge pinned to a card corner with absolute top-0 right-0.

A common pattern is a relative parent with an absolute child (a badge on a card corner) using absolute top-0 right-0 on the child.

Browsers give form controls inconsistent default styling, so most teams add the official forms plugin to reset them, then style with plain utilities: border, rounded, px-3 py-2, and focus:ring-2 for a visible focus state. The peer variant handles validation feedback with no JavaScript. Without the plugin you can still style inputs, but you'll fight more browser defaults, especially on checkboxes, radios, and selects.

Without the forms plugin you can still style inputs, but you'll fight more browser defaults, especially on checkboxes, radios, and selects.

Use aspect-* on the container (aspect-video for 16:9, aspect-square for 1:1, or an arbitrary ratio) and object-cover on the image so it fills the box without distortion, cropping the overflow. object-contain instead fits the whole image inside the box without cropping. This pairing gives you responsive media that holds its shape as the layout resizes, which also prevents layout shift while images load.

object-position utilities like object-top or object-center then let you choose which part of a cropped image stays visible, so a portrait keeps the face in frame rather than the chin.

The overflow utilities set what happens when content exceeds its box: overflow-hidden clips it, overflow-auto adds scrollbars only when needed, overflow-scroll always shows them, and the -x and -y variants target one axis. A scrollable panel with a fixed height is usually just h-64 overflow-y-auto. For long tables that would break the layout, overflow-x-auto on a wrapper keeps the page from scrolling sideways.

Pair these with whitespace-nowrap and truncate for text that should ellipsis rather than wrap, and with the scroll-snap utilities when you want a carousel that snaps to each item.

Tailwind scans your configured content for class-name-shaped strings, matches them against its utility definitions and your theme, and generates only the CSS rules for classes it found. The result is a stylesheet containing your resets, any component and utility layers, and nothing you didn't use.

In v4 the engine (Oxide, written partly in Rust) and automatic content detection make this faster and remove most manual content configuration. The core idea is unchanged: on-demand generation from detected class names.

Tailwind's build scans source files for complete class strings. A class assembled from fragments at runtime never appears as a literal in your files, so the scanner doesn't find bg-blue-500, doesn't generate it, and it's missing from the production CSS even though it worked in dev if you had it cached.

The fixes: write full class names in a lookup map so each literal is present, or safelist the classes in the config when the values are truly dynamic. Never build class names by interpolation.

v4 moved configuration into CSS with the @theme block and a single @import "tailwindcss" entry, replaced the JavaScript-config-first workflow, shipped a faster Rust-backed engine, and made content detection automatic so you rarely list paths by hand. It also leans on modern CSS features like native cascade layers and container queries.

The utility classes and the mental model carry over almost entirely, so migration is mostly about config location and a handful of renamed or removed utilities, not relearning Tailwind.

Map the design system's primitives (color ramps, spacing scale, type scale, radii, shadows) onto the theme so every value in the product comes from named tokens, not ad hoc numbers. Designers and engineers then share one vocabulary, and a token change updates everywhere at once.

The discipline that keeps it working: forbid arbitrary values for anything that has a token, review for one-off colors creeping in, and expose semantic aliases (surface, muted, danger) on top of raw ramps so intent survives.

Let the content scan do its job: ensure it covers exactly your template files and no vendored bundles, avoid dynamic class construction that forces broad safelisting, and keep arbitrary values rare since each unique one adds a rule. A well-configured Tailwind app ships a small stylesheet even at scale because unused utilities never generate.

Beyond generation, standard CSS delivery wins apply: minify, compress, and let the file cache since Tailwind output changes only when class usage does.

Utilities live in the utilities layer, which comes last, so a utility generally beats base and component styles. Between two utilities that set the same property, the winner is decided by source order in the generated CSS, not the order in your class attribute, which is why p-2 p-4 is ambiguous.

The clean fix is to not put conflicting utilities on one element; when composing dynamically, use tailwind-merge to resolve conflicts deterministically. The ! important modifier and cascade layers are the escape hatches when a third-party style intrudes.

Tailwind styles elements but ships no components, so ecosystems grew to fill that gap. Headless libraries (Radix, Headless UI) provide behavior and accessibility with no styling, and you apply Tailwind classes. Copy-in kits like shadcn/ui give you component source that already uses Tailwind and variant helpers, which you own and can edit.

The trade-off to articulate: shadcn/ui-style ownership keeps you in control and on your tokens, while an installed component library is faster to adopt but harder to restyle to a custom design system.

Utilities don't make markup accessible on their own, so the work is the same as any front-end: semantic elements, real focus states (focus-visible: rings rather than removing outlines), sufficient color contrast from the shade scale, and sr-only for screen-reader-only text. Tailwind gives you the tools (sr-only, focus-visible:, not-sr-only) but you have to use them.

A frequent regression is stripping focus outlines for looks; the accessible pattern replaces the default outline with a visible focus ring, never nothing.

Add Tailwind alongside the existing stylesheet and adopt it per component or per page, using the prefix option or scoped layers to avoid class-name collisions with legacy CSS. Tailwind's preflight reset can clash with existing base styles, so you may disable it or scope it during the transition.

The migration order that works: new features in Tailwind, then refactor high-churn components, leaving stable legacy CSS untouched until it's worth the effort.

A plugin is a function that receives helpers (addUtilities, addComponents, addVariant, matchUtilities, theme) and registers new classes or variants tied to your theme. matchUtilities is the one worth knowing: it generates a family of classes from a theme scale with arbitrary-value support built in, exactly like the core utilities.

You'd write one when a pattern recurs across projects (a custom variant, a utility family driven by tokens) and deserves to behave like first-class Tailwind rather than repeated @apply.

For unstyled content, ensure the generated stylesheet is linked in the document head and not loaded async, so styles arrive with the markup during server rendering. Tailwind's static CSS makes this straightforward because the styles don't depend on JavaScript executing.

For dark mode, the flash comes from resolving the theme after paint. The standard fix is a tiny inline script in the head that sets the dark class on html from stored preference before the body renders, so the correct theme is applied on the first paint.

Container queries size an element based on its parent container's width instead of the viewport, so a card component can reflow correctly whether it sits in a wide main area or a narrow sidebar. You mark a container with @container and use @-prefixed variants like @md:grid-cols-2 on children.

They matter for genuinely reusable components: a card that only knows its own container adapts anywhere, while viewport breakpoints force the component to assume where it lives on the page.

The real costs: markup gets verbose with long class strings, there's a learning curve for the naming system, and separating structure from styling is harder because they live together. Teams that dislike it usually hit the verbosity in deeply nested components.

Mitigations that actually work: extract components so long strings live once, use tailwind-merge and clsx for conditional composition, adopt the editor extension for autocomplete and linting, and enforce token use so arbitrary values don't sprawl. Being able to The downsides credibly is a production signal, not a weakness.

Use the official Prettier plugin to auto-sort class names into a canonical order, so diffs stay clean and reviewers stop arguing about ordering. Add the Tailwind ESLint plugin to catch contradictory classes and invalid class names, and the editor extension for autocomplete and hover previews.

Beyond tooling, agree on rules the linter can't fully enforce: prefer tokens over arbitrary values, extract components past a repetition threshold, and keep @apply for narrow cases.

Audit first: catalog the design tokens hiding in the legacy CSS (colors, spacing, type) and encode them in the Tailwind theme so the migration preserves the visual system. Introduce Tailwind side by side with a prefix or scoped layers to avoid collisions, disable or scope preflight so it doesn't reset legacy styles, and migrate by surface area starting with new work and high-churn components.

Track progress with a metric (percentage of components on Tailwind), keep both systems working during the transition, and delete legacy CSS only after its components are fully migrated. The technical sequence, audit, coexist, migrate by priority, retire, is what the question scores.

Tailwind's theme values can be backed by CSS custom properties, which is how v4 exposes tokens (colors, spacing) as variables you can read and override at runtime. That makes runtime theming (per-tenant brand colors, user-chosen accents) possible without regenerating CSS, since you swap variable values instead of classes.

The pattern: define semantic variables in the theme, reference them in utilities, and override the variables on a scope (a tenant wrapper) to reskin without touching markup.

Test behavior and accessibility, not class strings. Query by role and text with Testing Library, assert on what the user actually sees and can do, and use visual regression snapshots (Playwright, Chromatic) to catch styling regressions, since Tailwind utilities render to real CSS that a browser evaluates. That keeps tests tied to outcomes rather than to which utility classes happen to be present.

Asserting that an element has class bg-blue-600 is brittle and tests the implementation; a visual snapshot or a computed-style check is what actually verifies the styling held after a refactor.

Work from the most common cause outward. First confirm the class name appears as a complete literal in a scanned file, because a class built by string interpolation won't be generated. Then check the content config includes that file's path. Next rule out a conflicting utility on the same property, with CSS source order deciding the loser. Finally verify the production CSS built and shipped, not a stale cached copy.

The reason it can pass locally is that dev often generates a broader set of classes or serves a cached build, so the gap only shows once the production content scan runs cleanly. Reproduce with a production build locally to close the loop.

Acknowledge the point honestly, then reframe it. The classic separation put structure in HTML and styling in CSS, but in component-based apps the real unit of reuse is the component, which already owns its markup and styling together. Utility classes colocate styling with that unit instead of splitting it across files you have to keep in sync, so the concern being separated has shifted from files to components.

The trade is real: you accept busier markup for no dead CSS, no naming overhead, and styles you read in one place. Being able to argue both sides, rather than dismissing the criticism, is what a senior interviewer is actually probing.