Purpose of tailwind.config.js content array and JIT scanning

What's really being asked

This question probes whether you understand Tailwind's build-time architecture, specifically how the framework discovers utility classes and why its just-in-time compiler relies on explicit file paths rather than static analysis of your dependency graph. The interviewer wants to see that you know Tailwind scans source files as plain text, not parsed AST, and that the content array is the entry point for that scan.

The full answer

First, define the content array as a list of file path globs in tailwind.config.js that tells the JIT engine which source files to monitor and scan. Second, explain that the compiler reads these files as raw plain text, hunting for tokens that look like utility class names, then generates CSS on demand only for the classes it actually finds. Third, note that this scanning approach is what makes arbitrary values like bg-[#1da1f2] possible, because the JIT can spot the token and generate the corresponding custom property on the fly. Fourth, emphasize the production impact: without accurate content paths, Tailwind cannot discover your classes, so styles go missing; with correct paths, it tree-shakes CSS down to a few kilobytes gzipped instead of hundreds of kilobytes.

The mistakes people make

Do not describe the content array as a PurgeCSS configuration or CSS minification tool. Avoid saying Tailwind parses your JSX or TypeScript into an AST to extract classes; the docs explicitly state it treats files as plain text. Do not claim Tailwind generates all possible utilities by default and the content array filters them out afterward; the JIT engine only generates what it discovers. Never suggest that dynamically concatenated class names built from variables work reliably, since the scanner cannot interpolate strings.

What usually comes next

The interviewer may ask what happens if you forget to include a directory in the content array, expecting you to say styles simply do not appear. They might ask how to handle classes coming from node_modules or a component library, which requires adding those paths to content. They could also ask about dynamic class names and the safest patterns for conditional styling, or how Tailwind v4 changes this model by moving configuration into CSS imports.

A concrete example

Suppose your config includes content paths like ./src/*/.js and ./public/index.html. When you write a div with className set to flex gap-4 text-red-500 in a component, the JIT scanner finds the tokens flex, gap-4, and text-red-500 in that plain text file and emits exactly those three utility rules into the final stylesheet. If you omit the src directory from content, the scanner never opens that folder, sees no tokens, and outputs zero CSS for your components, leaving the page unstyled in production.